Management, Prevention, and Response Domains

From

editione1.0.0

Updated October 9, 2023
Now Available
Security for Everyone

Definition Management domains aim to set the direction and security expectations for your organization, and will often involve thinking about and planning how you would like security to be handled by your team. These practices and associated policies are then used as a measure to decide if your team has met your expectations when approaching security tasks.

Definition Prevention domains aim to identify risks and threats that apply to your business and take steps to reduce the likelihood of them happening. While there are no guarantees in security, and rarely can we be sure that we have stopped a security vulnerability from occurring, prevention aims to do the best we can to protect what matters.

Definition Response domains are those focused on events that could potentially happen. They are the mechanisms we use to predict and plan for security incidents and disruptions to our operations. These domains act like the cards in the seat back of your plane. While we all hope nothing goes wrong on our flight, we know it’s important to read the card and know what to do—just in case. These domains aim to respond quickly and effectively as bad things happen, so that we can minimize the impact on the business and restore operations to normal as soon as possible.

Let’s reorganize our domains by these categories.

Table: Security Domains by Category

ManagementPreventionResponse
• Security policy
• Organization of information security
• Compliance
• Asset management
• Human resources security
• Physical and environmental security
• Communications and operations management
• Access control
• Information systems acquisition, development and maintenance
• Information security incident management
• Business continuity management

As this table shows, there is a lot more for us to do when trying to practically protect our data and prevent security incidents than simply managing our security approach or planning our response. While the table is a simplification, it’s a nice reminder that our security to-do list is long and mostly contains changes we need to make to our systems and processes, rather than just creating documentation.

If you found this post worthwhile, please share!