Security control types: Examples, audit gaps, and how they work

Knowing the names of security control types is not the same as running a program that can survive an audit. Most teams are familiar with the taxonomy: preventive controls stop incidents, detective controls identify them, and corrective controls address them. 

What the taxonomy does not explain is why organizations with established controls still fail assessments, miss active threats, or cannot produce evidence when it matters.

The 2024 Snowflake-related breach campaign made that gap concrete. Attackers accessed approximately 165 customer environments not through a platform vulnerability, but through stolen credentials on accounts where multi-factor authentication was not consistently enforced. The preventive control existed as a feature. It simply was not applied.

That pattern is more common than most programs acknowledge. Controls exist on paper but are not enforced. Logs are collected but never reviewed. Policies are signed off on but cannot be evidenced over time.

Security controls do not fail only when they are absent. They fail when the mix is unbalanced, when operation cannot be verified, and when ownership is assumed rather than assigned.

This guide offers a practical map of every security control type, what auditors specifically test for, and the imbalance failures that sink real compliance programs.

What are security control types?

Security controls are the safeguards and countermeasures an organization puts in place to reduce the likelihood or impact of a security incident across its people, processes, and systems. Most compliance frameworks organize them across two dimensions: what a control does, and how it is delivered.

• Functional type

The first dimension is functional type, which describes the role a control plays in a security program:

• Preventive controls: They stop incidents before they occur
• Detective controls: These controls identify incidents as, or after they happen
• Corrective controls: They restore normal operations once something goes wrong
• Deterrent, compensating, and recovery controls: These controls extend this coverage further, depending on an organization's risk profile and compliance requirements

• Implementation category

The second dimension is implementation category, which describes the form a control takes:

• Administrative controls: These controls govern behavior through policies, procedures, risk assessments, and training programs 
• Technical controls: They enforce security requirements through systems, such as firewalls, MFA, encryption, and intrusion detection tools
• Physical controls: These types of controls protect access and the environment through mechanisms like badge readers, CCTV, and locked server rooms

These two dimensions are not separate checklists. They work together, and that relationship matters most during an audit. A single preventive control can be administrative (an access policy), technical (an MFA enforcement rule), or physical (a biometric entry system). 

Auditors verify not just that a control type exists, but that it is delivered through the right mechanism and that evidence of consistent operation can be produced.

The 3 implementation categories of security controls

Every security control belongs to one of three implementation categories. Understanding each category helps clarify not just what a control looks like, but who owns it and what evidence it produces.

1. Administrative controls

Administrative controls govern behavior through documented policies, procedures, and organizational processes. This category covers security awareness training, risk assessments, vendor management programs, onboarding-offboarding processes, and segregation of duties frameworks.

The important thing to understand about administrative controls is that they set intent, not enforcement. A password policy is an administrative control. It communicates what is required. Without a corresponding technical control enforcing that requirement at the system level, such as an Active Directory configuration that rejects non-compliant passwords, the policy carries little weight in an audit. Auditors look for the enforcement mechanism, not just the document.

2. Technical controls

Technical controls enforce security requirements through systems and technology. This category includes MFA, IAM policies, firewalls, encryption, SIEM platforms, endpoint detection and response tools, data loss prevention systems, IDS/IPS, access control lists, and vulnerability scanners.

Technical controls matter in audits because they generate the evidence trail that auditors actually examine. Configuration exports, log records, alert histories, and access review reports all originate from technical controls. 

A well-configured technical control does not just protect the environment; it produces the proof that protection is operating consistently.

3. Physical controls

Physical controls protect access to facilities, hardware, and infrastructure. This category covers badge access systems, CCTV, visitor logs, locked server rooms, equipment disposal procedures, and environmental monitoring systems.

Physical controls are frequently underestimated by cloud-native organizations, yet both ISO 27001 and SOC 2 include physical security requirements. For organizations without on-premises infrastructure, a colocation agreement that includes physical access logs and facility controls typically satisfies this requirement.

Because ownership gaps are one of the most common reasons evidence collection breaks down at audit time, it helps to know upfront which team is responsible for each category. 

The table below summarizes each implementation category, its common examples, and the teams typically responsible for ownership and evidence collection.

‍

The core functional control types mapped to audit reality

The functional type determines when a control acts and what evidence it produces. This is what auditors test.

Before going deeper into each type, the table below offers a quick reference for how the functional control types differ in application, with ownership included as a practical reference for evidence accountability.

1. Preventive controls

Preventive controls are designed to stop a security incident before it occurs. They form the first line of defense in any security program and are typically the category organizations invest in earliest.

From an audit perspective, preventive controls need to demonstrate more than existence. Auditors look for evidence that they are actively enforced across all accounts and systems in scope. This typically includes MFA enrollment reports, IAM configuration exports, firewall rule reviews, and training completion records.

The most common finding in this category is a gap between design and enforcement. According to Orca Security's 2024 State of Cloud Security Report, 61% of organizations have at least one root user or account owner without MFA enabled. 

The control exists as a capability. It is simply not enforced consistently across the accounts that need it most. That gap is what auditors record, and it is what attackers exploit.

2. Detective controls

Detective controls are designed to identify security incidents as they happen or after they have occurred. Where preventive controls limit exposure, detective controls provide visibility. Without them, a program cannot confirm whether its preventive controls are actually working.

From an audit perspective, detective controls require more than showing that tools are deployed. Auditors want to see that alerts are being reviewed and actioned. 

This means log retention records, SIEM alert documentation, access review completion records, and evidence that alerts were followed up within a defined SLA.

The most common finding here is a review cadence that exists informally but cannot be demonstrated. Logs are collected, and alerts are configured, but when an auditor asks who reviews them and how often, no documented process exists. 

A tool running unmonitored provides visibility in theory but offers no audit value in practice.

3. Corrective controls

Corrective controls are designed to minimize the impact of a security incident and restore normal operations. They represent a program's ability to respond effectively once something has gone wrong.

From an audit perspective, corrective controls are judged on proof of operation, not documentation alone. Auditors examine IR runbooks, patch deployment records, IR test results, backup restoration test logs, and incident tickets with resolution timestamps.

The most common finding in this category is an IR plan that has never been exercised. The document exists, and responsibilities are assigned, but when auditors ask for evidence of a tabletop exercise or a live recovery test, none can be produced. 

A corrective control that has never been tested cannot be relied upon when it is actually needed.

4. Deterrent controls

Deterrent controls are designed to discourage malicious or non-compliant behavior before it occurs. Unlike preventive controls, which technically block an action, deterrent controls work by making the consequences of that action visible. They influence behavior rather than restrict it.

Common audit evidence for deterrent controls includes acceptable use policy acknowledgment records, training completion logs, and login banner configurations that confirm users are warned before accessing systems.

The most common finding in this category is that deterrent controls are treated as one-time setup tasks rather than ongoing obligations. An acceptable use policy signed during employee onboarding in year one means little without a renewal or re-acknowledgment process in subsequent years. 

Auditors testing whether a control operated consistently across the audit period will look for exactly that evidence, and its absence is a common finding.  Deterrent controls are only as effective as the process that keeps them current and evidence-based.

5. Compensating controls

Compensating controls are alternative measures deployed when a primary control cannot be implemented due to technical, financial, or operational constraints. They are not a permanent substitute for the intended control but a documented interim measure that achieves an equivalent level of protection through a different approach.

Common audit evidence includes formal risk acceptance documentation and a written rationale demonstrating that the compensating control provides equivalent protection to the primary control it replaces.

The most common finding with compensating controls is that they are declared verbally during an audit interview with no supporting documentation. 

Auditors require a formal written rationale to accept them. A verbal assertion, however well-intentioned, carries no audit weight.

6. Recovery controls

Recovery controls focus on restoring systems, data, and operations to a normal state following a disruption. Where corrective controls address the immediate response to an incident, recovery controls address the longer process of returning to full operational capacity.

Common audit evidence includes DR test results, backup restoration logs, documented recovery time objectives and recovery point objectives, and evidence that those targets have been validated against actual recovery performance.

The most common finding here is a DR plan that exists as a document but has never been tested. Documented RTO and RPO targets mean little if no test has confirmed they can actually be met.

What breaks when controls are unbalanced

Most compliance failures are not caused by having no controls at all. They happen when organizations over-invest in one control type while neglecting the others. A mature security program needs prevention, detection, correction, and governance working in concert. 

When one layer is strong and the others are weak, the gap eventually surfaces in a breach, an outage, or an audit finding.

Scenario 1: Preventive-only programs

Many organizations invest carefully in preventive controls: MFA, access restrictions, endpoint hardening, and network segmentation. These controls are essential, but they address only one part of the equation.

The SolarWinds supply chain attack illustrated why prevention alone is not sufficient. Attackers injected malicious code into trusted Orion software updates distributed to approximately 18,000 customers. 

Because the malware was delivered through a trusted update mechanism and designed to blend in with legitimate traffic, it went undetected for approximately nine months in many affected environments. (Source: CISA, 2021) 

Where log monitoring was limited, and anomaly detection was weak, the activity remained invisible long after initial compromise.

In audits, teams with strong prevention but limited monitoring capability consistently struggle to demonstrate how they identify anomalies, review access logs, or detect unauthorized activity over time.

The real problem is not the absence of preventive controls. It is that auditors and leadership cannot confirm that the organization knows when those controls fail.

Scenario 2: Detective controls without a corrective response

Some organizations build capable detective programs. SIEM platforms are deployed, alerts are configured, and dashboards are monitored. Suspicious activity becomes visible quickly.

But visibility does not resolve incidents on its own.

The Colonial Pipeline ransomware attack in May 2021 is instructive here. According to CISA's advisory, the organization's emergency response plan did not specifically consider cyberattacks, and response exercises had not provided employees with decision-making experience in dealing with them.

When the attack occurred, the organization shut down pipeline operations proactively due to uncertainty about the extent of the compromise, not because it lacked detection capability. The gap was in the corrective layer: a tested, practiced response process.

In audits, assessors review sampled alerts and ask for investigation notes, escalation evidence, remediation records, and closure timelines. When alerts exist but documented responses are missing or inconsistent, findings follow.

The real problem is that detection creates a false sense of readiness. Knowing something is wrong and having a systematic, tested way to address it are two entirely different capabilities.

Scenario 3: Administrative controls without technical enforcement

Some organizations maintain polished policy libraries. Password standards, access control policies, and acceptable use rules are formally approved and signed by leadership. On paper, the governance program looks mature.

Real environments often tell a different story.

The Uber breach in September 2022 demonstrated what happens when administrative controls are not reinforced by technical safeguards. An attacker obtained a contractor's credentials, then bypassed MFA through a fatigue attack, flooding the contractor with push notifications until one was approved. 

Once inside, the attacker found hardcoded privileged credentials in PowerShell scripts on a network share, enabling lateral movement across internal systems. The access control policy existed. The technical enforcement did not match it.

Auditors regularly compare documented policy against actual system configurations and operational evidence. If a policy requires strong authentication, quarterly access reviews, or least privilege access, they expect proof that those controls operate in practice, not just in documentation.

The real problem is that policies without corresponding technical enforcement provide legal cover but no actual protection. A policy document does not stop an attacker. The system configuration either does or it does not.

What auditors actually expect across control types

Knowing what controls to implement is one thing. Knowing what auditors will look for when they test those controls is another. Across every control type, auditors are essentially testing four things: 

• Design (does the control exist?)
• Operation (is it running as intended?) 
• Evidence (can you prove it?)
• Ownership (does someone have clear accountability for it?)

A gap in any one of these dimensions can produce a finding, even when the control itself is technically in place.

What auditors look for by control type

The evidence expectations vary depending on the control type being tested. The table below maps each category to the artifacts auditors typically request and the points where programs most commonly fall short.

The operating effectiveness standard

This is the detail that many teams miss until their first Type II audit. SOC 2 Type II and ISO 27001 surveillance audits do not simply verify that controls exist. They test whether controls operated effectively across the entire audit period, which typically spans six to twelve months.

Evidence collected on the day an auditor arrives covers only that day. What auditors want to see is a continuous record of operation: recurring access reviews, regular log review documentation, tested backups, and policies that were actively maintained throughout the period under review.

The distinction matters because a control that cannot be evidenced over time is treated the same as a control that does not exist. Teams that collect evidence reactively, assembling records only when an audit is approaching, consistently produce the same findings, cycle after cycle. 

The ones that avoid repeat findings build evidence collection into routine operations rather than treating it as an audit-season activity.

How security controls map to compliance frameworks

Different frameworks emphasize different control types. Knowing which ones your framework tests hardest helps you prioritize investment and evidence collection before an auditor asks.

NIST Cybersecurity Framework

NIST CSF organizes security activities across six functions, each of which maps directly to a functional control type:

• Govern: Govern maps to administrative controls: policies, risk assessments, and oversight processes that underpin every other function
• Identify: Identify maps to administrative controls: asset management, risk assessment, and understanding the organizational environment
• Protect: Protect maps to preventive and deterrent controls: access management, awareness training, and data protection measures
• Detect: Detect maps to detective controls: continuous monitoring, anomaly detection, and security event analysis
• Respond: Respond maps to corrective controls: incident response planning, containment, and remediation workflows
• Recover: Recover maps to recovery controls: restoration of systems, services, and operations following a disruption

Govern was introduced in CSF 2.0, released in 2024, formally recognizing that administrative controls are not a supporting layer but the foundation on which all other functions depend. (Source: NIST CSF 2.0, 2024)

ISO 27001

ISO 27001 Annex A contains 93 controls organized across four themes, each mapping directly to the implementation categories covered earlier in this article:

• Organizational: Organizational controls cover governance structures, policies, roles, and responsibilities, and map directly to administrative controls within a security program
• People: People controls address human factors, including screening, training, awareness, and disciplinary processes, and also fall under the administrative controls category
• Physical: Physical controls govern access to facilities, equipment protection, and environmental security, mapping directly to the physical controls implementation category
• Technological: Technological controls cover technical safeguards, including access management, encryption, logging, and incident response, mapping to the technical controls implementation category

ISO 27001 auditors test both design and operating effectiveness, meaning a control must exist and demonstrably work. Among the most commonly under-evidenced controls in certification audits are A.8.15, which covers logging and monitoring, and A.5.26, which addresses response to information security incidents.

SOC 2

The SOC 2 Trust Services Criteria place particular scrutiny on two functional control types, and understanding which criteria map to each helps teams prepare the right evidence:

• Detective controls: They fall under the CC7.x series, which covers system monitoring, anomaly detection, and the identification of security incidents as they occur. Evidence must demonstrate that monitoring was active and alerts were reviewed and actioned throughout the audit period, not just at the point of assessment
• Corrective controls: These fall under the CC4.x series, which covers the identification and remediation of control deficiencies identified during monitoring or through other means. Evidence must show that deficiencies were logged, assigned, and resolved within a documented process

Because SOC 2 Type II audits test operating effectiveness across the full audit period, continuous evidence of both control types is required rather than a point-in-time snapshot.

PCI DSS

PCI DSS Requirement 10 is a pure detective control requirement, mandating logging and log monitoring across all components within the cardholder data environment. Requirement 12 addresses administrative controls, covering security policies, risk assessments, and third-party management obligations.

The table below summarizes where each framework concentrates its scrutiny, which is useful when deciding where to prioritize evidence collection efforts.

From audit-season scramble to always audit-ready

Most compliance programs run on a reactive cycle. Controls are implemented, evidence is gathered when an audit approaches, gaps are patched under pressure, and the cycle repeats. It works, until it does not.

The shift to continuous evidence collection is not just an operational preference. It is what modern frameworks demand. SOC 2 Type II tests whether controls operated across the full audit period. 

ISO 27001 surveillance audits expect evidence of ongoing effectiveness, not a snapshot assembled in the final weeks. In each case, the question auditors are really asking is not “do your controls exist today?” but “have your controls been working all along?”

Answering that question confidently requires a program where evidence is a byproduct of routine operations, ownership is defined and tracked, and gaps surface before an auditor finds them.

This is precisely what Scrut is built for. Scrut's AI-powered compliance platform automates evidence collection, maps controls to framework requirements in real time, and gives compliance teams live visibility into control posture throughout the year, not just at audit time.

See how Scrut turns continuous compliance into a competitive advantage.