2) Identify risks and policies There are several ways to identify risks and the policies required to manage them. The first is to identify standard IT operational policy controls used to protect critical information and assets and test to ensure they work. The risk of control failure can be calculated based on knowing how sensitive the protected information is, and how likely the control is to fail. Regulatory requirements often specify controls, but should not be assumed comprehensive for most organizations.Prioritizing risk (based on criticality) before policy control testing minimizes the amount of testing and the disruption caused when too many survey questions are posed to busy operations staff. It also provides IT operations with a basis for prioritizing the often complex task of fixing failed controls. 3) Test controls and identify gaps For most organizations, control testing is typically a tedious, expensive process involving project management of questionnaires distributed to IT server and application owners, as well as gathering automated data from vulnerability scanners, security incident logs and network change management systems. From the mass of data gathered, gaps in the infrastructure are identified that require mitigation. Most organizations end up with "test fatigue" if they have no way of identifying what's critical and what's not, especially when testing is required for more than one regulation, like Sarbanes-Oxley 404 and PCI. Establishing a common set of critical controls that get tested once for multiple regulations is key to maximizing efficiencies and minimizing "burnout." 4) Optimize mitigation When hundreds of such control tests are performed, optimizing the work implied by the outcome requires application of risk scoring techniques. Risk scores are determined by asking key questions about the control, such as:
Another means to identify risks is to look at what others have already done to think through the problem. Organizations such as consultancies Deloitte Touche Tohmatsu and Protiviti have established IT-specific KRIs (key risk indicators) such as:
- Third-party and system breaches
- Changes resulting in production system disruptions
- Unavailability of qualified IT staff
- How critical, in terms of business continuity or data privacy and protection, is the protected system to the business or to customers, regulators, partners, or shareholders?
- How much exposure does the protected system have to other systems, such as the Internet or partner systems, and how many users access the system?
- How likely is this system to fail the control test based on past performance or other information?