Study guide

3.1 Document and Maintain Functional Security Controls

ISC2 Systems Security Certified Practitioner SSCP

Track your progress as you read

Finished sections get a check mark.

1 Introduction and Exam Overview

1.1 Current Exam Facts 1.2 Computerized Adaptive Testing, Scoring, and Retakes 1.3 Eligibility, Associate Pathway, Endorsement, and Maintenance

2 Ethics and Security Concepts

2.1 Comply with Codes of Ethics 2.2 Understand Security Concepts 2.3 Identify and Implement Security Controls

3 Functional Controls, Assets, and Change Management

3.1 Document and Maintain Functional Security Controls 3.2 Support and Implement the Asset Management Lifecycle 3.3 Support and Implement the Change Management Lifecycle

4 Security Awareness and Physical Security Operations

4.1 Support and Implement Security Awareness and Training 4.2 Collaborate with Physical Security Operations

5 Authentication Methods and Trust Architectures

5.1 Implement and Maintain Authentication Methods 5.2 Federated Access with OAuth2, SAML, and OpenID Connect 5.3 Understand and Support Internetwork Trust Architectures

6 Identity Lifecycle and Access Control Models

6.1 Support and Implement the Identity Management Lifecycle 6.2 Mandatory, Discretionary, and Role-Based Access Control 6.3 Rule-Based, Attribute-Based, and Privileged Access Management

7 Risk Management, Visibility, and Legal Concerns

7.1 Risk Management Concepts and Treatment 7.2 Risk Visibility, Reporting, and Threat Intelligence 7.3 Legal and Regulatory Concerns

8 Assessments, Monitoring, and Analysis

8.1 Security Assessments and Vulnerability Management 8.2 Operate and Monitor Security Platforms 8.3 Analyze Monitoring Results

9 Incident Response and Forensic Investigations

9.1 Incident Response: Preparation, Detection, Analysis, and Escalation 9.2 Containment, Eradication, Recovery, and Lessons Learned 9.3 Understand and Support Forensic Investigations

10 Business Continuity and Disaster Recovery

10.1 Business Continuity and Emergency Response 10.2 Disaster Recovery and Restoration Metrics 10.3 Backup, Redundancy, Testing, and Drills

11 Cryptography Foundations

11.1 Reasons and Requirements for Cryptography 11.2 Hashing, Salting, Symmetric, Asymmetric, and ECC 11.3 Digital Signatures, HMAC, Algorithm Strength, and Cryptanalysis

12 Secure Protocols and Public Key Infrastructure

12.1 Understand and Implement Secure Protocols 12.2 Understand Public Key Infrastructure

13 Networking Fundamentals, Attacks, and Access Controls

13.1 Understand and Apply Fundamental Concepts of Networking 13.2 Understand Network Attacks and Countermeasures 13.3 Manage Network Access Controls

14 Network Security Operations, Wireless, and IoT

14.1 Manage Network Security 14.2 Operate and Configure Network-Based Security Appliances and Services 14.3 Secure Wireless Communications 14.4 Secure and Monitor Internet of Things

15 Malware, Malicious Activity, and Endpoint Security

15.1 Identify and Analyze Malicious Code 15.2 Malicious Activity, Social Engineering, and Behavior Analytics 15.3 Implement and Operate Endpoint Device Security

16 Mobile, Cloud, and Virtual Environments

16.1 Administer and Manage Mobile Devices 16.2 Cloud Security: Deployment, Service Models, and Shared Responsibility 16.3 Cloud Legal, Regulatory, and Third-Party Requirements 16.4 Operate and Maintain Secure Virtual Environments

3.1 Document and Maintain Functional Security Controls

Key Takeaways Explain This Topic AI

Control functions (deterrent, preventative, detective, corrective, compensating) describe what a control does; categories (technical, physical, administrative) describe how it is implemented.

A login warning banner is a deterrent; it does not block a session the way multi-factor authentication (MFA) does as a preventative control.

Security information and event management (SIEM), intrusion detection, and log review are detective; restore-from-backup and reimage are corrective.

Compensating controls (isolation plus extra monitoring) apply when a primary preventative control such as patching is blocked; document an owner, evidence, and review date.

Document controls in a catalog (function, category, owner, scope, evidence, review cycle) and re-test them after environmental change so they do not rot.

Last updated: August 2026

Document and Maintain Functional Security Controls

Domain 1 of the ISC2 Systems Security Certified Practitioner (SSCP) exam — Security Concepts and Practices, weighted at 16% — tests whether you can document and maintain functional security controls , not merely recite a list. Knowledge Area 1.3 asked you to identify and implement controls by category : technical, physical, and administrative. Knowledge Area 1.4 asks a different operational question: what job does this control perform?

If you collapse those two taxonomies, you will miss items that look easy. A lock is a physical control by category and a preventative control by function. A legal warning banner is often technical (the operating system renders it) or administrative (policy requires it), and it is a deterrent by function. Security information and event management (SIEM) is a technical detective control. Restoring a file share from backup is corrective . Extra monitoring on an unpatchable medical device is compensating .

The SSCP is an operational credential. Items are framed the way a sysadmin , asset owner , or change advisory board (CAB) member actually works: classify the function, write it down, and keep it working after the environment changes.

Categories Versus Functions

Memorize this split before you memorize examples.

Dimension Control categories (Knowledge Area 1.3) Control functions (Knowledge Area 1.4)

Question answered How and where is the control implemented? What purpose does it serve in reducing risk?

  • Types Technical, physical, administrative Deterrent, preventative, detective, corrective, compensating
  • Multi-factor authentication (MFA) Technical Preventative
  • Locked server-room door Physical Preventative (and somewhat deterrent)
  • Closed-circuit television (CCTV) Physical Detective if it records; also deterrent if it is visible
  • Acceptable-use policy Administrative Preventative and deterrent
  • Extra intrusion detection system (IDS) on a host that cannot be patched Technical Compensating (and detective)

One control can wear more than one function. Visible cameras deter and detect. A firewall rule prevents and , if logged and reviewed, supports detection. When an item asks for the primary function, pick the purpose the scenario emphasizes.

The October 1, 2025 SSCP outline spells this family preventative . Many textbooks and National Institute of Standards and Technology (NIST) publications say preventive . Treat the spellings as the same function.

Deterrent Controls

A deterrent control discourages someone from attempting an unwanted action. It does not, by itself, block the action. Think of it as a psychological or legal speed bump, not a gate.

Operational examples:

Login warning banners on Secure Shell (SSH), Remote Desktop Protocol (RDP), and virtual private network (VPN) portals stating that unauthorized access is prohibited and monitored

  • "Premises under video surveillance" signs at a data-center dock
  • Uniformed guards in a lobby (visibility is the deterrent; the badge check is preventative)
  • Published sanctions in an acceptable-use policy

Scenario. You administer a jump host. Policy requires a pre-authentication banner: "This system is for authorized users only. Activity is logged. Unauthorized access will be prosecuted." That banner does not reject a stolen password. MFA does that. The banner exists so a later investigation can show the user was warned, and so a casual attacker thinks twice. If an item describes a banner and asks for the function, the answer is deterrent, not preventative.

Deterrents fail against a motivated adversary. They still belong in defense in depth because they reduce opportunistic attempts and support legal process.

Preventative (Preventive) Controls

A preventative control stops the event from occurring, or makes successful occurrence much harder. This is the "keep it from happening" layer.

Operational examples:

  • MFA on VPN, email, and privileged access
  • Firewall and access control list (ACL) denies
  • Encryption in transit and at rest
  • Least privilege and segregation of duties (SoD)
  • Input validation, allowlisting, and secure defaults
  • Physical locks, mantraps, and disabled Universal Serial Bus (USB) ports
  • Timely patching of known exploited vulnerabilities

Scenario. An attacker phishes a help-desk technician's password. MFA on the VPN is the preventative control that keeps that password from becoming a session. The warning banner did not stop the login attempt; MFA did.

Do not call logging preventative just because logs exist. Logs that nobody reviews are not even reliably detective. Preventative means the control intervenes before the harm completes.

Detective Controls

A detective control identifies that an event is happening or has happened. Detection does not stop the first occurrence; it creates visibility so you can respond.

Operational examples:

  • SIEM correlation rules and dashboards
  • Network or host IDS
  • File integrity monitoring
  • Audit-log review and privileged-session recording
  • CCTV review (as distinct from the sign that advertises the camera)
  • Honeypots and canary tokens
  • Account-lockout alerts (the lockout itself is preventative; the alert is detective)

Scenario. Your SIEM fires on fifty failed authentications against a privileged account from an unusual geolocation. That alert is detective. The lockout threshold that stopped the fifty-first try is preventative. Restoring the account after a confirmed compromise is corrective.

On the exam, "we send it to the SIEM" is almost always detective. "We restored from backup" is corrective. Do not blend them.

Corrective Controls

A corrective control returns the environment to a known-good state after an incident or failure. Correction is not prevention with a new name; it is recovery and repair.

Operational examples:

  • Restore from last night's backup after ransomware encrypts a departmental share
  • Reimage a compromised workstation

Apply an emergency patch after an exploit was observed (the patch going forward is preventative; restoring the damaged host is corrective)

  • Quarantine and clean malware, then recertify the host
  • Revoke a stolen certificate and issue a replacement

Scenario. Ransomware encrypts a finance file share. The asset owner authorizes a restore of last night's snapshot, the sysadmin brings the share back, and incident response blocks the entry point. The restore is corrective. A new MFA rule on the VPN the attacker used is preventative going forward. The SIEM rule that finally fired is detective — and if it fired too late, you document that gap.

A scheduled backup job enables correction; it does not prevent ransomware from encrypting files. Do not mark "we take backups" as preventative against malware execution.

Compensating Controls

A compensating control provides equivalent or acceptable protection when the primary control cannot be implemented. The language is familiar from the Payment Card Industry Data Security Standard (PCI DSS), but SSCP uses it more broadly: the preferred preventative control is blocked, residual risk is still too high, and you add other functions — often isolation plus extra detection — to bring risk within appetite.

Typical blockers include vendor warranty, clinical uptime, a mainframe change window, a third-party appliance with no agent, or a contractual constraint.

Scenario. A hospital magnetic resonance imaging (MRI) workstation cannot be patched this quarter because the vendor has not certified the operating-system update. You cannot claim "we patched." Compensating controls might include a dedicated virtual local area network (VLAN) with no internet path, jump-host-only administration, host-based IDS, 24/7 SIEM monitoring with a tuned use case, and an accelerated replacement project. Extra monitoring is not a patch. It is compensation, and it must be documented with an owner, evidence, and a review date.

Compensating controls are not a permanent excuse to skip hardening. They are time-bounded alternatives with monitoring and a plan to restore the primary control.

Defense in Depth on One Asset

Put all five functions on a single production file server so the relationships stick:

  • Function Example on the finance file server
  • Deterrent Legal banner on administrative logon; acceptable-use policy for shares
  • Preventative MFA for admin; share ACLs; encryption in transit and at rest
  • Detective SIEM collection; file integrity monitoring; alert on bulk-encrypt patterns
  • Corrective Nightly backups with a tested restore; reimage runbook

Compensating If the vendor blocks the integrity agent, increase SIEM fidelity and isolate the host until an approved agent ships

Document and Maintain

Knowledge Area 1.4 is not only vocabulary. Document means a control catalog or register. Maintain means you re-test after changes, patch the control itself (SIEM content, IDS signatures, backup jobs), and retire controls that no longer map to a live risk.

  • Catalog field Why the SSCP cares
  • Control identifier Traceability in audits and tickets
  • Function Deterrent, preventative, detective, corrective, or compensating
  • Category Technical, physical, or administrative
  • Asset or system scope What the control actually covers
  • Owner Accountability when it fails
  • Evidence location How you prove it operates
  • Review date Maintenance, not "set and forget"
  • Residual risk / expiry Especially for compensating controls

Controls rot. A SIEM use case that still points at a decommissioned Internet Protocol (IP) address is a documented detective control that no longer detects. An SSCP who deployed MFA last year and never reviewed exceptions has failed the maintain half of the objective.

When you sit the exam, classify first by function (what job), then by category (how implemented), then ask whether the control is still in production, owned, and evidenced.