What Is a Program Framework Policy or Charter?

The program framework policy, or information security program charter, is the capstone document for the information security program. The charter is a required document that establishes the information security program and its framework. This high-level policy defines:

The chief executive officer (CEO) usually approves and signs the charter. The charter establishes the responsibility for information security within the organization. It’s important that senior leadership of an organization express support for the information security program. This support comes in many forms. For instance, it’s not unusual for the CEO to attach a personal message to the release of an information security program charter, or as part of an annual information security awareness effort. This responsibility is often placed on an individual known as the chief information security officer (CISO). The CISO is responsible for the development of the framework for IT security policies, standards, and guidelines. The CISO also approves and issues these documents. One of the CISO’s primary roles is to ensure adherence to regulations. The regulations may be at the local, state, or federal level. The CISO also sets up a security awareness program. The program helps employees understand and live up to the organization’s information security policies, standards, guidelines, and procedures.

FYI

The CISO may also be known by many other titles, depending on the culture of the organization. The CISO role is functionally aligned to the top-ranking individual who has full-time responsibility for information security. Some examples include:

  • Director of information security
  • Chief security officer
  • Director of risk and compliance
  • Information security program manager

Information security teams must ensure that security policies comply with laws and regulations; however, information security personnel are not lawyers. They work with their organizations’ compliance and legal teams to gain an understanding of legal requirements. That is different from determining whether an organization is violating a law. That is the task of the legal department—and if it’s not done properly there, the matter may be settled in court. In other words, the information security team must determine violations of an organization’s security policy but should never express an opinion on violations of law. If a law appears to have been broken, a host of complex issues may arise, such as: What was the intent behind the actions taken? Was anyone’s behavior reckless?

It’s best for information security teams to express violations in terms of security policies. Information security leadership should ensure policies comply with legal requirements, and there should be a process for reporting major violations to compliance and/or legal departments.

Purpose and Mission

This part of the policy states the purpose and mission of the program. You should define the goals of the IT security program and its management structure. The needs can form the basis of the program’s goals. Integrity, availability, and confidentiality are common security-related needs. Most e-commerce systems maintain confidential personal data. In this case, the goals might include stronger protection against unauthorized disclosures.

You should create a structure that addresses alignment with program and organizational goals. Your policies should mirror your organization’s mission and goals. They should describe the operating and risk environment of the organization within this structure. Important issues for the structure of the information security program include:

  • Management and coordination of security-related resources
  • Interaction with diverse communities
  • The ability to communicate issues of concern to upper management

Scope

A policy’s scope specifies what the program covers. This usually includes resources, information, and personnel. In some instances, a policy may name specific assets, such as major sites and large systems.

Sometimes, you must make tough management decisions when defining the scope of a program. For example, you may need to decide how the program applies to contractors who connect to your systems. The same concept applies to external organizations.

TIP

Align scope with your annual information security budget. If scope and budget are not in alignment, you may be committing to something you cannot deliver.

Responsibilities

A policy should state the responsibilities of personnel and departments related to the program. This includes the role of managers, users, and the IT organization. This is also referred to as the program’s delegation of authority.

TIP

Distinguish the responsibilities of computer services providers from those of the managers of applications who use the computer services. This policy can also serve as the basis for establishing employee accountability.

Compliance

Compliance is the ability to reasonably ensure conformity and adherence to both internal and external policies, standards, procedures, laws, and regulations. A program-level policy should address enforcement of the policy; for example, what happens if someone doesn’t comply with computer security policies?

The program-level policy is a high-level document. It usually does not include penalties and disciplinary actions for specific infractions; however, this policy may authorize the creation of other policies or standards that describe violations and penalties. One common strategy for handling this issue is to have the information security policy refer to disciplinary procedures found elsewhere, such as in a human resources (HR) policy that broadly covers disciplinary actions.

NOTE

An employee can unintentionally violate a policy. For example, an employee may lack knowledge or training. This can result in noncompliance.

Some organizations create a specific consequence model for information security policy violations. A consequence model does not replace the broader HR polices that deal with disciplining individuals. A consequence model is not intended to be punitive for the individual. Its purpose generally is to remove the risk introduced by the policy violation. For example, suppose a security policy has strict control requirements for coding applications that face the Internet. Assume an information security scan of a newly deployed interfacing application found a security weakness in direct violation of the policy. A consequence model (based on level of risk) could give the developer x days to fix the code to be in compliance. The consequence of failing to fix the code within the prescribed time would be to take the application offline and remove the risk.

Industry-Standard Policy Frameworks

Policy frameworks provide industry-standard references for governing information security in an organization. They allow you to leverage the work of others to help jump-start your security program efforts. The following areas determine where framework policies are helpful:

  • Areas where there is an advantage to the organization in having the issue addressed in a common manner, such as shared IT resources
  • Areas that affect the entire organization, such as personnel security
  • Areas for which organization-wide oversight is necessary, such as compliance
  • Areas that, through organization-wide implementation, can result in significant economies of scale, such as unified desktop computer management

No two organizations are alike. For-profit companies may have different goals and concerns than nonprofit organizations or government agencies. Different needs require different solutions. Therefore, security professionals have a wide variety of policy frameworks to work with. It’s up to each organization to determine the best policy framework that meets the needs of the organization and the threats they face.

Three frameworks stand out because of their scope and wide acceptance within the security community:

  • Control Objectives for Information and related Technology (COBIT)—A widely accepted set of documents that is commonly used as the basis for an information security program. COBIT is an initiative from ISACA, formerly known as the Information Systems Audit and Control Association, and is preferred among IT auditors. Keep in mind that COBIT was updated in 2019 to COBIT 2019.
  • ISO/IEC 27000 series—An internationally adopted standard, the ISO/IEC 27000 series can be found in the information security management program of virtually any organization.
  • National Institute of Standards and Technology (NIST) Special Publications, such as (SP) 800-53, “Recommended Security Controls for Federal Information Systems and Organizations”—Geared to U.S. government agencies and their subcontractors.

Many of the regulatory bodies use these standards to develop security guidance and auditing practices. By relying on those who have paved the way for you, you can help to assure compliance with regulations that affect your organization without reworking all of your compliance processes. The following sections offer details on how to use the ISO/IEC 27002, 30105, and 27007 standards and the NIST SP 800-53 standard to describe your policy framework.

ISO/IEC 27002 (2015)

The International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) develop and publish international standards. These standards are published as ISO/IEC numbered designations. It’s common to see these standards abbreviated as ISO. For example, the ISO/IEC 27002 standard is often shortened to ISO 27002.

NOTE

ISO is actually not an acronym. It is short for isos, which is the Greek word for equal.

ISO/IEC 27002 is titled “Information Technology—Security Techniques—Code of Practice for Information Security Controls.” This is a popular industry standard for establishing and managing an IT security program. ISO/IEC 27002 outlines 15 main areas that compose the framework:

  1. Foreword—Describes the overall purpose and key references for the document. This includes the following key areas:
    • Scope
    • Terms of reference
    • Structure of the document
  2. Information security policy—Describes how management should define an information security policy. Organizations usually maintain detailed security policies in a library. Information security standards, procedures, and guidelines support the library.
  3. Organization of information security—Describes how to design and implement an information security governance structure. This section describes the need for an internal group that manages the program, including the governance of business partners.
  4. Human resources security—Describes security aspects for employees joining, moving within, or leaving an organization. The organization should manage system access rights. The organization should also provide security awareness, training, and education. Section 4 covers these employment phases:
    • Prior to employment
    • During employment
    • Termination or change of employment
  5. Asset management—Describes inventory and classification of information assets. The organization should understand what information assets it holds, and manage their security appropriately. This section covers responsibility for assets and information classification.
  6. Access control—Describes restriction of access rights to networks, systems, applications, functions, and data. This section addresses controlled logical access to IT systems, networks, and data to prevent unauthorized use. The following topics are covered:
    • Business requirements for a control
    • User access management
    • User responsibilities
    • Network access control
    • Operating system access control
    • Application and information access control
    • Mobile computing and remote employee access
  7. Cryptography—Describes the use and controls related to encryption. This includes the following key control areas:
    • Cryptographic authentication
    • Cryptographic key management
    • Digital signatures
    • Message authentication
  8. Physical and environmental security—Describes protection of computer facilities. Valuable IT equipment should be physically protected against malicious or accidental damage or loss, overheating, loss of main power, and so on. This section covers:
    • Secure areas
    • Equipment security
    • Critical IT equipment, such as cabling and power supplies
  9. Operations security—Describes operational management of controls to ensure that capacity is adequate and performance is delivered. This section includes these key topics:
    • Operational procedures and responsibilities
    • Protection against malicious and mobile code
    • Backups
    • Logging and monitoring
    • Information systems audit coordination
  10. Communications security—Describes securing the network and controlling access to information by third parties. This section includes these topics:
    • Third-party service delivery management
    • Network security management
  11. Systems acquisition, development, and maintenance—Describes building security into applications. Information security must be taken into account in the systems development life cycle (SDLC) processes for specifying, building/acquiring, testing, implementing, and maintaining IT systems. These activities include the following:
    • Security requirements of information systems
    • Correct processing in application systems
    • Cryptographic controls
    • Security of system files
    • Security in development and support processes
    • Technical vulnerability management
  12. Supplier relationships—Describes the policy and procedures needed to monitor suppliers’ information security controls. This includes but is not limited to:
    • How suppliers access company information
    • How suppliers access the company network
    • Monitoring access and activity of suppliers when they are on the organization’s network
    • Managing access rights when supplier personnel change roles
    • Auditing suppliers to service level agreements
  13. Information security incident management—Describes anticipating and responding appropriately to information security breaches. Information security events, incidents, and weaknesses should be promptly reported and properly managed. This section of the standard covers:
    • Reporting information security events and weaknesses
    • Managing information security incidents and improvements
  14. Information security aspects of business continuity management—Describes protecting, maintaining, and recovering business-critical processes and systems. This section describes the relationship among IT disaster recovery planning, business continuity management, and contingency planning, ranging from analysis and documentation through regular exercising/testing of the plans. Controls are designed to minimize the impact of security incidents that occur despite the preventive controls from elsewhere in the standard.
  15. Compliance—Describes areas for compliance, which include:
    • Compliance with legal requirements
    • Compliance with security policies and standards, and technical compliance
    • Information systems audit considerations

ISO/IEC 27002 covers the three aspects of the information security management program: managerial, operational, and technical activities. All three must be present in any IT security program for comprehensive coverage. For more information about ISO/IEC 27002, visit http://www.iso27001security.com/html/27002.html.

ISO/IEC 30105

ISO/IEC 30105, “Information Technology—IT Enabled Services-Business Process Outsourcing (ITES-BPO) Lifecycle Processes,” covers outsourced processes. Some processes are outsourced in every organization. There must be clear policies that govern the entire outsourcing process, including methods, procedures, and operations.

There are five parts to this standard:

  • Part 1: Process reference model
  • Part 2: Process assessment model
  • Part 3: Measurement framework and organization maturity model
  • Part 4: Terms and concepts
  • Part 5: Guidelines

In relationship to frameworks, clearly Part 3 is of interest, but so is Part 5. This standard specifies all the steps in outsourcing, including planning, establishing, operating, monitoring, reviewing, maintaining, and improving services. Given the ubiquitous nature of outsourcing at least some business functionality, it is worthwhile to have at least a general understanding of this standard.

ISO 27007

The ISO 27007 standard, “Information Technology—Security Techniques—Guidelines for Information Security Management Systems Auditing,” was first published in 2011 and was revised in 2017. When it was revised again in 2020 the name was changed to “Information Security, Cybersecurity, and Privacy Protection — Guidelines for Information Security Management Systems Auditing”. This standard governs compliance auditing for information technology. This may seem far removed from frameworks; however, it provides a basis for any framework. Looking at the security policy framework from the perspective of compliance with audit requirements can be an effective approach for many organizations.

NIST Special Publication (SP) 800-53

NIST is an agency of the U.S. Department of Commerce. NIST develops information security standards and guidelines for implementing them. NIST SP 800-53, “Security and Privacy Controls for Federal Information Systems and Organizations,” is the primary standard for federal systems.

Organizations often rely on NIST publications for reference and to develop internal IT security management programs. NIST SP 800-53 uses a framework similar to ISO/IEC 27002; however, NIST SP 800-53 includes 18 areas that address managerial, operational, and technical controls. TABLE 6-1 summarizes NIST SP 800-53 rev. 4.

TABLE 6-1 A Summary of NIST SP 800-53
CONTROL AREA DESCRIPTION
Access Control Limit information system access to:
  • Authorized users
  • Processes acting on behalf of authorized users
  • Devices (including other information systems)
  • The types of transactions and functions that authorized users are permitted to exercise
Awareness and Training Ensure that managers and users of information systems are aware of the security risks associated with their activities. Ensure adequate training for personnel to carry out their assigned information security–related duties and responsibilities.
Audit and Accountability

Create, protect, and retain information system audit records. Records include those for monitoring, analysis, investigation, and reporting of unlawful, unauthorized, or inappropriate information system activity.

Users are accountable for their actions.
Security Assessment and Authorization

Periodically assess the security controls in information systems to determine if the controls are still effective.

Develop and implement plans of action that correct deficiencies and reduce or eliminate vulnerabilities in information systems.

Continually monitor information system security controls to ensure their effectiveness.
Configuration Management

Establish and maintain baseline configurations and inventories of information systems throughout their life cycles.

Establish and enforce security configuration settings for devices in use.
Contingency Planning Establish, maintain, and implement plans for:
  • Emergency response
  • Backup operations
  • Postdisaster recovery
Identification and Authentication

Identify information system users.

Verify the identities of those users, as a prerequisite to allowing access to information systems.
Incident Response

Establish an incident handling process for information systems.

Track, document, and report incidents to appropriate officials and/or authorities.
Maintenance Perform periodic and timely maintenance on information systems. Provide effective controls to conduct information system maintenance.
Media Protection

Protect information system media, both paper and digital.

Limit access to information on information system media to authorized users.
Physical and Environmental Protection

Limit physical access to information systems, equipment, and operating environments to authorized people.

Protect the support infrastructure for information systems.

Protect information systems against environmental hazards.

Provide environmental controls for all information systems.
Planning Develop, document, periodically update, and implement security plans for information systems. Describe the security controls in place or planned for the information systems. Include the rules of behavior for accessing the information systems.
Personnel Security

Determine that individuals in positions of responsibility are trustworthy and meet established security criteria for those positions, including third-party service providers.

Maintain the protection information systems during and after terminations and transfers.

Employ consequences for people failing to comply.
Risk Assessment Periodically assess the risk to operations, assets, and people when using information systems or transmitting information.
System and Services Acaquisition

Allocate sufficient resources to protect information systems.

Employ system development life cycle processes that incorporate information security considerations.

Ensure that third-party providers employ adequate security measures to protect information, applications, and/or services.
System and Communications Protection

Monitor, control, and protect information transmitted or received by information systems at perimeter and important boundaries of the information systems.

Employ architectural designs, software development techniques, and systems engineering principles for effective information security.
System and Information Integrity

Identify, report, and correct information and information system flaws in a timely manner.

Provide protection from malicious code at appropriate locations within information systems.

Monitor information system security alerts and advisories and take appropriate actions in response.
Program Management Ensure the ongoing operation of the Information Security program.

For more information about NIST SP 800-53, visit https://nvd.nist.gov/800-53

Version 4 of this standard was published in February 2012. The fifth version of this standard had a final draft release in March 2020 and is set for publication in late 2020. The basics of the standard are the same, but have been enhanced in the following ways:

  • Making the security and privacy controls outcome-based
  • Integrating privacy controls into the security control catalogue
  • Deemphasizing the federal focus of the publication to encourage greater use by nonfederal organizations
  • Promoting integration with different risk management and cybersecurity approaches
  • Incorporating new, state-of-the-practice controls based on threat intelligence and empirical attack data

What Is a Policy?

Policies are an important part of an information security program. They are best defined as high-level statements, beliefs, goals, and objectives. Policies help protect an organization’s resources and guide employee behavior. Security policies help you address critical computer security issues. With effective policies in place, your organization will have better protection of systems and information.

Security policies also provide the “what” and “why” of security measures. Procedures and standards go on to describe the “how” of configuring security devices to implement the policy. The lack of information security policies and enforcement leaves an organization vulnerable to data breaches, business interruptions, and legal liabilities. In fact, in many states, not having or not enforcing information security controls in accordance with industry norms could lead to jail time for business owners and executives. There’s a lot at stake. Yet, despite the urgent need and potential legal liabilities, many organizations do not have the defined security policies they need. As far back as 2012, a study by Symantec reported that of 1015 small and midsize companies in the United States, 83 percent had no cybersecurity plan. A more recent report, from 2019, states that on average a breach will cost a company 200,000 US dollars.1 This can put many smaller businesses out of business. Implementing a good set of security policies can be a major competitive advantage. It ensures the protection of customer information and the stability of the business systems, and it protects the company from legal liabilities. These formal definitions of policies versus procedures are not always so clear in practice. In some organizations, what are actually procedures may be referred to as policies.

The IT security program begins with statements of management’s intentions. These intentions are documented as policies. Policies describe the following:

  • Details of how the program runs
  • Who is responsible for day-to-day work
  • How training and awareness are conducted
  • How compliance is handled

The following is an example of a high-level policy that establishes an IT security program:

Executive Management endorses the mission, charter, authority, and structure of Information Security. The Company’s Executive Management has charged Information Security with the responsibility for developing, maintaining, and communicating a comprehensive information security program to protect the confidentiality, integrity, and availability of Company information resources.

Write policies as broad statements that describe the intent of management, defining the direction for the organization. Make these statements nonspecific as to how that will be accomplished. You should include details about how to meet the policy in a family of documents below the high-level policy.

What Are Standards?

You have many choices when deciding how to protect your computer assets. Some choices are based on quantifiable tradeoffs. Other choices involve conflicting tradeoffs and questions related to your organization’s strategic directions. When making these choices, the policies and standards you establish will be used as the basis for protecting your resources—both information and technology—and for guiding employee behavior.

Standards are formal documents that establish:

  • Uniform criteria that you can evaluate and measure
  • Methods to accomplish a goal
  • Repeatable processes and practices for compliance with policies

Security standards provide guidance towards achieving specific security policies. Although security policies are written at a high level, there’s insufficient detail to explain how people should support them.

Security standards are often related to particular technologies or products. They are used as benchmarks for audit purposes and are derived from:

  • Industry best practices
  • Experience
  • Business drivers
  • Internal testing

Standards can come in different forms. Two common forms are control or issue-specific standards and system-specific technical or baseline standards.

Issue-Specific or Control Standards

An issue-specific standard focuses on an area of current relevance and concern to your company. Be prepared for frequent revision of these standards because of changes in technology and other related factors. As new technologies develop, some issues diminish in importance while new ones continually appear. For example, it might be important to issue a standard on the proper use of a cutting-edge technology even if the security vulnerabilities are still unknown.

A useful structure for issue-specific or baseline standards is to break the document into basic components. The components are described in the following sections.

Statement of an Issue. This section defines a security issue and any relevant terms, distinctions, and conditions. For example, an organization might want an issue-specific policy on the use of Internet access. The standard would define which Internet activities you permit and those you don’t permit. You may need to include other conditions, such as prohibiting Internet access using a personal connection from an employee’s desktop PC.

Statement of the Organization’s Position. This section should clearly state an organization’s position on the issue at hand. To continue with the example of Internet access, the policy should state which types of sites are prohibited. Examples of these sites may be pornography, brokerage, and/or gambling sites. The policy should also state whether further guidelines are available, and whether case-by-case exceptions may be granted, by whom, and on what basis.

Statement of Applicability. This section should clearly state where, how, when, to whom, and to what a particular policy applies. For example, a policy on Internet access may apply only to the organization’s on-site resources and employees and not to contractors with offices at other locations.

Definition of Roles and Responsibilities. This section assigns roles and responsibilities. Continuing with the Internet example, if the policy permits private Internet service provider (ISP) accesses with the appropriate approvals, identify the approving authority in the document. The office or department(s) responsible for compliance should also be named.

Compliance. This section gives descriptions of the infractions that are unacceptable and states the corresponding penalties. Penalties must be consistent with your personnel policies and practices and need to be coordinated with appropriate management.

Points of Contact. This section lists the areas of the organization accountable for the policies’ implementation. These are typically the subject matter experts (SMEs). They interpret the policy. Often they are also in charge of ensuring the controls are in place to enforce the policy. This section may also identify other applicable standards or guidelines. For some issues, the point of contact might be a line manager. For other issues, it might be a facility manager, technical support person, systems administrator, or security program representative.

System-Specific or Baseline Standards

A system-specific standard, or baseline standard, is focused on the secure configuration of a specific system, device, operating system, or application. Many security policy decisions apply only at the system level.

Examples include:

  • Who is allowed to read or modify data in the system?
  • Under what conditions can data be read or modified?
  • What firewall ports and protocols are permitted?
  • Are users allowed to access the corporate network from home or while traveling?

What Are Procedures?

A procedure is a written instruction on how to comply with a standard. A procedure documents a specific series of actions or operations that are executed in the same manner repeatedly. If properly followed, procedures obtain the same results under the same circumstances. Procedures support the policy framework and associated standards by codifying the steps that are proven to yield compliant systems.

Procedures should be:

  • Clear and unambiguous
  • Repeatable
  • Up to date
  • Tested
  • Documented

Examples of procedures include:

  • Incident reporting
  • Incident management
  • User ID addition/removal
  • Server configuration
  • Server backup
  • Emergency evacuation

A single standard often requires multiple procedures to support it. The people responsible for supporting or operating technical equipment in compliance with a standard are often the same people who document procedures to meet compliance requirements. Security department personnel may assist with documenting procedures. Once approved, the procedures are published within the policy and standards library with appropriate controls over who has access to them. Procedures are usually where metrics are collected to monitor compliance. Consequently, it’s important to understand how these new procedures impact any governance and oversight. For example, assume there’s a weekly oversight meeting to review the volume of user ID changes such as adding and deleting accounts. Also assume there’s a dashboard that breaks down weekly activity to itemize the types of changes that occurred. This type of dashboard is common to try to proactively identify problem areas and detect unusual activity.

A new procedure may be introduced to remove dormant accounts. A dormant account is typically one that has not been used for an extended period of time. When this new procedure was put in place to remove dormant accounts, it would directly impact the weekly oversight meeting. In other words, you need to not only implement the new security procedure, but also update the weekly dashboard. Additionally, you need to discuss with the members of the weekly oversight meeting the ramification of the process change made.

NOTE

Some procedures may be proprietary or contain trade secrets. They may also contain sensitive information on how security is monitored and controlled. These procedures may not be suitable for broad access by all employees.

FIGURE 6-3 illustrates an example of an extract of a policy and standards library. The figure highlights an access control policy, which is one of many security-related policies.

A flow diagram of an access control policy branch of a policy and standards library.

FIGURE 6-3 A possible access control policy branch of a policy and standards library.

Exceptions to Standards

Situations arise in which your organization cannot meet one or more standards immediately. You must recognize an exception to standards to determine where problems may exist.

Periodic reviews of these exceptions can also lead to improvements to the standards when many exceptions point to a general inability to meet compliance goals. Paying attention to exceptions is vital to ensuring that the policy framework remains relevant and current.

Exceptions are seldom approved “forever.” Typically, they are reexamined annually. This allows leadership to discuss whether they are willing to accept the risk for another year or fund the changes needed to ensure compliance with security policies. Exceptions often include a discussion of compensating controls and mitigating controls. Compensating controls mean that although you cannot meet the letter of the policies, you can still achieve their goals through other means. Mitigating controls mean that although you cannot meet all the policies’ goals, you can still achieve partial compliance. It’s important to understand when you are approving a security exception how much risk you are accepting.

What Are Guidelines?

IT security managers often prepare guidelines, or guidance documents, to help interpret a policy or a standard. Guidelines may also present current thinking on a specific topic. Guidelines are generally not mandatory—failing to follow them explicitly does not lead to compliance issues. Rather, guidelines assist people in developing procedures or processes with best practices that other people have found useful. A guideline can also clarify issues or problems that have arisen after the publication of a standard.

NOTE

You usually do not invent best practices—you adopt them from others. Following best practices helps you avoid making mistakes that others have already learned from. This is a primary reason for being fully involved in the IT security industry. You can learn from peers about concerns and problems that led them to improved processes and technologies.

You can think of guidelines as “standards in waiting.” They are used where possible, and feedback on guidelines is given to IT security managers responsible for policy and standards maintenance. Guidelines provide the people who implement standards or baselines more detailed information and guidance (hints, tips, processes, etc.) to aid in compliance. These documents are optional in a library but are often helpful.

Eventually, a guideline may become a standard when its adoption is widely accepted and implemented. For example, assume you have guidelines outlining five acceptable encryption techniques. Of the five, assume three become so widely adopted by the development teams that they are used in 95 percent of all applications. A decision could be made to make those three the standard for all new development. You can then treat the other two techniques, used in 5 percent of the application, as exceptions, or you can budget to upgrade them.

TIP

Joining an association focused on IT security is a good way to meet peers and develop skills. There are many associations you can join, including ISACA (isaca.org), ISC2 (ISC2.org), and ISSA (issa.org).

 

1https://www.cnbc.com/2019/10/13/cyberattacks-cost-small-companies-200k-putting-many-out-of-business.html