3.1 Document and Maintain Functional Security Controls

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.

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:

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.

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.