.png)
Security categories for an organization’s information systems need to be defined to enable appropriate risk decisions to be made.
Without this, organizations could potentially expend resources to protect a lower impact, lower risk system instead of focusing attention on a higher impact or higher risk system. Security categorization and risk framing are the focus of Pitfall #13 in my eBook, Security Program Pitfalls and Prescription to Avoid Them, which fits great with Friday the 13th later this week.
It is important to protect all systems, but protection levels should be based on the level of risk defined for information systems. They should be categorized based on the information they process, store, or transmit in accordance with applicable laws, directives, policies, regulations, standards, and guidance. Additionally, categorization should be based on the business importance or criticality of information systems. A system authorizing official, or a designated representative, should review and approve all security categorization decisions.
Security categorization results, including the supporting rationale, should be documented in a System Security Plan (SSP). Even if an SSP is not a regulatory requirement for any of your organization’s production systems, implementing an SSP is an effective way to identify a system’s security categorization. An SSP also contains control information, along with specific details on how control requirements are being addressed.
Once information security categorization is complete, critical system components and functionality should be identified at key decision points throughout the system development life cycle (SDLC) to ensure that appropriate controls are addressed throughout all SDLC phases. Remember, the SDLC process does not end when a system goes into Production. It continues until systems or system components are decommissioned and disposed. Assumptions or constraints should be identified that could affect risk assessments, risk responses, and associated risk monitoring. The risk tolerance for your organization defined by the risk appetite statement should take priorities and trade-offs into consideration for managing risk throughout the SDLC.
To learn more about this pitfall, and 99 more, get my eBook: 100 Security Program Pitfalls and Prescriptions to Avoid Them (available on Amazon here). Or register for a demo of the ASECENT Security and Compliance Portal and get a free synopsis of the 100 Security Program Pitfalls eBook today.