2.3 Identify and Implement Security Controls

Controls are how 1.1 and 1.2 become real

Knowledge area 1.3 — Identify and implement security controls — is the SSCP's implementation layer for the concepts in 1.2 and the duties in 1.1. A canon that says "protect the infrastructure" is empty until someone places a firewall, writes a baseline, and locks the cage. The October 2025 outline groups controls the way operations teams buy and run them: technical, physical, and administrative, plus the two management jobs that keep those controls honest — assessing compliance requirements and periodic audit and review.

Do not confuse this taxonomy with Domain 1.4's functional types (deterrent, preventive, detective, corrective, compensating). Those describe what a control does in an attack sequence. 1.3 describes what kind of thing it is and who runs it. A firewall is typically a technical, preventive control. A camera is typically a physical, detective control. A password standard is an administrative control that may be preventive. Exam items will ask you to classify the example, not to invent a new category.

Technical controls

Technical controls (also called logical controls) are hardware, software, and firmware that enforce policy automatically.

The outline's examples are the ones to keep on the tip of your tongue:

• Firewalls — devices or host software that allow, deny, or inspect traffic between zones using rules. On an SSCP shift you care about placement (perimeter, internal segmentation, host), default-deny, change control on rules, and logging of denies. A firewall with permit ip any any at the bottom of the last policy is a router with extra blinkenlights.
• Intrusion detection systems (IDS) — sensors that compare traffic or host behavior to signatures and baselines and alert. Network IDS is usually passive (out of band, tap or span port). Host IDS watches local files and processes. Detection without a playbook is noise. Detection that nobody can see because the sensor is in bypass is a false sense of safety.
• Access control lists (ACL) — ordered permit/deny statements on routers, switches, operating systems, or cloud security groups. ACLs implement least privilege on the wire and on the object. A too-permissive leftover from a vendor's lab template is a classic operations finding.

Other technical controls you will implement alongside those three include MFA, encryption, endpoint detection, and SIEM parsers. They still count as technical; the exam's listed trio is the classification core.

Technical controls fail in predictable ways: shadow rules, expired certificates, sensors left in "detect only" forever, and ACLs copied from a proof-of-concept. They also cannot replace a person walking a visitor through a propped-open door. That is why 1.3 insists you can identify and implement — a purchased IDS that was never tuned is not an implemented control.

Physical controls

Physical controls protect people, facilities, and hardware in the real world.

• Mantraps (access-control vestibules) — two-door spaces that allow only one person through after a badge or biometric success. They are used at data-center perimeters and cash rooms to stop tailgating. A mantrap that is overridden with a furniture wedge during a tour is not a control that day.
• Cameras — closed-circuit coverage of ingress, cages, loading docks, and sometimes console rooms. Cameras are usually detective; they do not block a door. Retention period, privacy signage, and who can review footage are part of the control, not extras.
• Locks — mechanical and electronic locks on rooms, racks, cages, and laptop cable anchors. A lock with a master key in an unlocked drawer is not a control.

Physical security operations (outline 1.8) go deeper on badging and visitors. Here you only need to recognize that a camera, a mantrap, and a lock are physical, and that they support CIA in a building: confidentiality of the server hall, integrity of the hardware, availability of power and cooling that people cannot casually sabotage.

A SOC analyst working remote is not protected by the data-center mantrap. That is why technical VPN and MFA controls still matter, and why physical and technical controls are stacked rather than swapped. The loading-dock camera does not stop a contractor from emailing a spreadsheet; the firewall does not stop a tailgater from walking into the cage.

Administrative controls: policies, standards, procedures, baselines

Administrative controls (also called managerial or procedural controls) are the documents and processes that tell people what "good" looks like.

SSCP candidates mix these up. A policy is not a how-to. A procedure that exists only as tribal knowledge is not an administrative control you can audit. A baseline that lives in one engineer's home directory will drift the first time that engineer is on leave. Administrative controls are what make technical and physical controls repeatable: the firewall change procedure, the camera-footage request process, the mantrap visitor log.

When a manager asks you to skip a control, the first artifact you point to is often administrative — the change policy, the access standard, the visitor procedure — and then you implement a technical or physical alternative that still meets it. Skipping the paperwork is skipping the administrative control; that is still a 1.3 failure even if the packets happen to flow.

Assessing compliance requirements

Assessing compliance requirements means identifying which external and internal obligations apply, then mapping them to implemented controls. Sources include law and regulation (for example, the Health Insurance Portability and Accountability Act (HIPAA) privacy and security rules when you handle electronic protected health information, or data-protection law in the jurisdiction where you process personal data), contracts and industry standards such as the Payment Card Industry Data Security Standard (PCI DSS) if you handle branded payment cards, and internal policy.

The practitioner job is not to memorize every framework clause. It is to:

1. Confirm applicability (are we a HIPAA covered entity or business associate? do we store cardholder data?).
2. Extract the control objectives that operations must meet (unique IDs, audit trails, physical access, encryption, visitor logs).
3. Map each objective to a technical, physical, or administrative control that already exists — or flag a gap.
4. Refuse to claim "we are compliant" without evidence. A policy binder with no firewall logs is a gap, not a pass.

Compliance is not the same as security, but on the SSCP it is a driver for which controls you must implement and keep. A control you cannot show to an assessor is a control you may as well not have when the contract is on the line. Mapping also prevents decorative controls: buying a mantrap because a glossy checklist mentioned one, while the actual obligation was unique IDs and ninety-day log review, wastes money and still fails the assessment.

Reassess when the environment changes. A new SaaS payroll system, a new state privacy law, or a customer contract with a right-to-audit clause can add requirements overnight. The SSCP who only assessed compliance at go-live is already stale.

Periodic audit and review

Periodic audit and review is how you prove controls still work. Examples include quarterly privileged-access recertification, annual firewall-rule reviews, baseline drift scans, visitor-log sampling, and tabletop reviews of IDS alert handling. Internal audit, external assessors, and the operations team itself all participate. The SSCP's role is usually to produce evidence — tickets, screenshots, log extracts, configuration hashes — and to fix findings.

Scenario: incomplete audit evidence

You are pulling artifacts for a quarterly access review. Forty privileged accounts were supposed to be recertified. Twenty-eight tickets have the manager's comment, a screenshot of the role, and a timestamp. Twelve tickets are empty shells: no screenshot, no approver named, some closed by the same administrator who holds the account. Closing the audit as passed because "most of them look fine" fabricates a clean sample. Deleting the twelve tickets to make the packet pretty is an integrity and ethics failure (Canons I and II from 1.1). Waiting for next year's external audit to mention it is not diligent service.

The correct operational move is to document the incomplete evidence as a finding, retain the original tickets, require the control owner to complete recertification with supporting artifacts, and track the gap to closure. If the twelve accounts include a shared NetAdmin identity, you have also found a least-privilege and accountability failure, not only a paperwork problem. Incomplete evidence is itself a control failure: a recertification that cannot be shown did not happen.

Audit cadence should match risk and obligation. A payment-card firewall rule review on a five-year cycle is not periodic in any useful sense. A daily recertification of 4,000 accounts that nobody actually reads is theater. SSCP items often test whether you keep evidence, whether you sample honestly, and whether you escalate systemic gaps rather than painting over them. Review also catches drift: an IDS signature set that has not been updated, a camera that has pointed at a wall since a remodel, a baseline that still allows SSHv1.

Selecting and stacking controls

Identify the asset and the concept you are protecting, then pick at least one control from more than one category. Customer databases in a cage typically need a lock and camera (physical), an ACL and database authentication (technical), and a standard plus access-review procedure (administrative). A manager who wants to "just skip the mantrap this week for tours" is asking you to remove a physical control; the ethics pattern from 1.1 applies, and you offer a compensating escort procedure rather than an open door.

AI-enabled controls — a machine-learning-tuned IDS, an automated firewall, a camera with people-counting — still need an owner, a baseline, change management for model updates, and audit evidence. Automation does not move a control out of its category, and it does not remove the need for periodic review.

When you implement, write down: what it is (technical, physical, or administrative), what concept it serves (CIA, accountability, least privilege, SoD), who operates it, what evidence it produces, and when that evidence is reviewed. That record is what 1.3 is testing, and it is what keeps you from confusing a policy with a firewall, or a camera with a completed audit.