Regulatory compliance is a significant undertaking for a number of organizations. Some organizations have full-time teams dedicated to collecting, reviewing, and reporting to show adherence to regulations. This diverts resources that could have been applied to protect the business.

The IT policies framework helps reduce this cost by defining security controls in a way that clearly aligns with policies and regulatory compliance. The better an organization can inventory and map its controls to policies and regulation, the lower its costs to demonstrate compliance. From a controls design view, best practice frameworks provide the mapping to major regulations such as the Sarbanes-Oxley (SOX) Act. As a result, the adoption of these frameworks is a quick way to demonstrate adequate coverage of regulatory IT requirements. However, good design and effective coverage of regulatory requirements don’t necessarily guarantee that the controls are working. The more an organization can automate, the lower the cost to demonstrate compliance. This is because automation reduces the time to gather documentation, test controls, and gather evidence. Two key areas of automation are documentation and testing.

Automating documentation for IT security controls simply means capturing the policy and regulatory requirements at the time the control was designed and implemented. The level of automation does not require sophistication. The core requirement of the automation is that the information is searchable. Documenting the information in multiple places in a format that cannot be searched is not automation. When the information is centralized and searchable, it’s much easier to explain to a regulator how the organization is compliant. The ability to search a list of controls also makes it easier to determine which controls need to be tested. There’s a vast array of low-cost documentation library solutions that can be used for this purpose.

Automating the testing of IT controls is harder but yields the greatest benefit. The type and level of automation will depend on the technology, the control, and the complexity of the IT environment. For example, many tools can compare a file of active employees from an HR database to a list of active accounts. If the control to remove an individual is working, you should not see former employees with active accounts. Providing the same level of assurance manually would be far more costly and prone to errors. Manual verification in a larger population of users would be statistically based. You cannot check every account manually. You would instead sample past and current employees. Depending on the number of errors an auditor finds, an opinion would be made about the overall population of active accounts.

Automated testing tools are often shared across the enterprise to improve operational effectiveness. For example, assume the automated testing of a control identifies a defect. The defect is reported and fixed. During the next test, another defect is found, reported, and fixed. The cycle continues. The individuals responsible for security control often adopt the testing tool to validate their own controls. In the real world, these individuals are motivated to avoid repeated audit findings. As a result, automation of compliance tests builds collaboration and improves operational effectiveness.

Testing for compliance is more complex than the few simple examples provided. Although the complexity and volume are much larger, the key concepts are the same. It’s the complexity of the technology and infrastructure that prevents wide-scale automated compliance testing today. Not all controls can be tested automatically. However, the goal should be to design controls that can be tested with automated tools.

Business requirements lead to controls, which lead to reduced risk. Regardless of framework, the core objective of reducing risk remains the same. The frameworks listed in Table 8-1 can address many business risks. There are many other types of nontechnology risks, well beyond the scope of these frameworks, such as credit or market risks. These are risks associated with customers being unable to pay, or market changes in which there’s no longer a demand for the product or service.

Business risks are defined as six specific risks, as follows:

• Strategic—Strategic risks are a broad category focused on an event that may change how the organization operates. Some examples might be a merger or an acquisition, a change in the industry, or a change in the customer. The key point is that it’s an event that affects the entire organization.
• Compliance—Compliance risks relate to the impact to the business of failing to comply with legal obligations. Noncompliance can be willful, or it can result from being unaware of local legal requirements. This can include regulatory requirements or legally binding contracts. Let’s say a company accepts the rules associated with processing credit cards but fails to implement PCI DSS. The card companies, under a binding contract, can force the merchant to stop taking credit cards.
• Financial—Financial risk is the potential impact when the business fails to have adequate liquidity to meet its obligations. This is when you fail to have adequate cash flow. For example, the consequences of failure to pay loans, payroll, and taxes would be financial risks. This lack of available funds can be due to a poor credit rating or operations too risky for banks to fund. Regardless of the reason, if you are unable to meet your financial obligations, that would be a financial risk.
• Operational—Operational risks are a broad category that describes any event that disrupts the organization’s daily activities. The Office of the Comptroller of the Currency (OCC) defines operational risk as “the risk of loss resulting from inadequate or failed internal processes, people and systems, or from external events.”¹ In technology terms, it’s an interruption of the technology that affects the business process. This can be a coding error, slow network, system outage, or security breach.
• Reputational—A reputational risk results from negative publicity regarding an organization’s practices. This type of risk could lead to a loss of revenue or to litigation. These risks often overlap with other risk categories; for example, a financial issue is likely to have a deleterious impact on the organization’s reputation.
• Other—Other risks is a broad category of non-IT-specific events that introduce risk to the line of business. Typically, this category of risk relates to events that are outside the organization’s control. For example, political unrest can occur in another country where the organization has a call center. The political unrest is a non-IT event. Lack of personnel showing up for work could impact IT operations. Although these risks may be outside of the organization’s control, they can still be planned for in much the same way natural disasters are planned for.