Breaking Down Security Controls: A Bite-Sized GuideGet the information you need to understand what security controls are and what they mean for your organization under different frameworks.
Security controls are a critical element of any IT strategy. However, it’s a common misconception that the number of controls correlates to a level of difficulty in achieving compliance. As with many things in the world of compliance, there is more to the story.
To determine what security controls are appropriate for your needs, you must first consider the risk that your organization faces and the requirements that you may need to meet. In this post, we’ll tell you what you need to know about security controls and share a few best practices based on different frameworks.
What Are the Types of Security Controls?
Security controls are broken down into categories. They can either be broken down based on the type of control (physical, administrative, or technical) or based on the purpose of the control (preventive, detective, corrective).
Controls may be categorized based on any combination of type and purpose. For instance, a control can be categorized as a preventive physical control, or a corrective technical control.
Each of these categories of controls plays a key role in both proactively addressing risk and responding to threats when they appear. To provide the best security for your organization and its data, you need to consider all of them.
Physical controls protect your resources and infrastructure from physical threats such as theft or damage. These controls exist on-premise to help you manage the environment where critical information exists.
Examples of physical controls include:
Video surveillance equipment
Access cards that limit entry into restricted areas
Administrative controls involve policies, procedures, and guidelines which are put in place to ensure that human error does not create security vulnerabilities for the organization. This is key because approximately 88% of all data breaches are caused by employee error.
Examples of administrative controls include:
Password expiration policy
Technical controls include hardware, software, and firmware that is used to prevent unauthorized access to systems or data. Controls at this level act as another line of defense if an unauthorized user were to gain access to your devices.
Examples of technical controls include:
Preventative controls are there to prevent or decrease the chances of an information security incident. Controls at this level allow you to take a proactive approach and build a security-first culture within your organization.
Examples of preventative controls include:
Segregation of duties
Security awareness training
Detective controls are put in place to help you identify irregularities or problems when an information security incident occurs. They can also help you determine whether your preventative controls are working properly.
Examples of detective controls include:
Security information and event management
Data leakage detection
Corrective controls act after an information security incident or problem has been detected. These controls are there to remedy flaws, make improvements, and guide corrective action.
Examples of corrective controls include:
Incident management and planning
Disaster recovery planning
Although the examples above are not exhaustive lists of possible controls, they can give you an idea of what you can implement across different control types.
What is the Main Goal of Security Controls?
The goal of security controls is to protect your data and systems from unauthorized access or use. You should use security controls for everyone—from passwords for online accounts to monitoring your network for attacks.
The important thing to remember is that security controls are not something you can set and forget. When you take part in an audit, you’ll need to take steps to ensure specific controls are in place and working properly.
You’ll also need to take steps to address new risks, continuously update and test your programs, and maintain compliance.
Number of Security Controls Through Different Frameworks
There are several different security frameworks organizations can use to help prove that assets secure. The number of controls you will need to implement depends on the criteria and requirements that apply to your organization based on the framework.
Keep in mind that the below is simply a generalized breakdown to give you a ballpark on the number of controls for each framework.
Depends on which categories (Availability, Confidentiality, Processing Integrity, Privacy) are included in your audit in addition to Security. Controls aren’t defined by SOC 2, so there can be a wide range of controls included in an audit.
Organizations define their own controls and your auditor will use their professional judgment to render an opinion on whether the controls you have in place meet the SOC 2 criteria for the categories in scope.
Average number of controls: Typically between 80 to 150
ISO 27002 defines ISO 27001 Annex A controls. You can identify controls from any source, however, the controls they use must be compared to the Annex A controls to determine that all Annex A controls are covered. Organizations complete an SOA (Statement of Applicability) to determine which Annex A controls apply.
Number of Annex A controls that must be covered:
ISO 27002:2013 – 114
ISO 27002:2022 – 93
If you’re required to complete Self-Assessment Questionnaire (SAQ) D or engage a Qualified Security Assessor to complete a Report On Compliance (ROC), you will be subject to all required controls, unless you deem controls not applicable. Other self-assessment questionnaires will require less controls.
Number of controls if all PCI controls are in scope:
PCI v3.2 – about 350
PCI v4.0 – about 400
HITRUST recently released the new i1 assessment. The i1 assessment does not take into account an organization’s inherent risk factors like the r2 assessment considers.
For r2 assessments, each control is divided into three implementation levels with multiple requirements. Organizations have to determine the implementation level for each control and tailor the controls based on risk. Once the implementation level and risk is determined, the number of required controls can be determined. i1 assessments won’t have implementation levels.
Even though there are more controls in an i1 assessment, it will require less effort since implementation levels in r2 assessments have several items to consider.
Number of controls:
i1 assessment – 219
r2 assessment – 156
For the r2 assessment, there can be as many as 1000 sub requirements. Most organizations are able to significantly reduce the number of control requirements after they determine which control requirements are necessary based on risk.
The number of required controls is based on the control baselines: LI-SaaS, Low, Moderate, High. Organizations must determine the impact level of the system being assessed as defined in FIPS 199.
The security controls and enhancements were selected from the NIST SP 800-53 Revision 4 catalog of controls.
Number of Controls:
High – 421
Moderate – 325
Low – 125
LI-SaaS – 126
This certification has three levels. Level 1 is for organizations handling Federal Contract Information only and Levels 2 and 3 are for organizations handling Controlled Unclassified Information.
Level 1 encompasses the basic safeguarding requirements in FAR Clause 52.204-21. Level 2 encompasses the security requirements for CUI in NIST SP 800-171 Rev 2 per DFARS Clause 252.204-7012. Information on Level 3 will be released at a later date and will contain a subset of the security requirements specified in NIST SP 800-172.
Number of Controls:
Level 1 – 17
Level 2 – 110
Level 3 – 110+
For Level 3, the total number of controls will be determined by the Department of Defense at a future date.
Looking for the smartest way to continuously monitor your controls for SOC 2, ISO 27001, PCI DSS, GDPR, CCPA, and HIPAA in one place? Drata can help. Schedule a demo to see how our solution can play a role in streamlining the process.