SSCP Domain 1, Security Concepts and Practices: what the exam asks and where candidates slip

Approving changes based solely on functional test results without performing security validation or threat modeling introduces significant risk. A change may work operationally but contain vulnerabilities.

1. AMore functional testing repeats what already passed; it does not look for security weaknesses.
2. BA failover test checks recoverability, not whether the change introduces a vulnerability.
3. CCorrect: a security impact assessment with threat modeling is the CAB step that catches vulnerabilities functional tests miss.
4. DDocumentation updates support users but do nothing to assess the security of the change.

More below: why each option is right or wrong — scroll this panel

Organizations must continuously verify vendor security posture via periodic reviews and SLA monitoring rather than focusing solely on initial assessments. Re-running the entire onboarding process is inefficient, immediate termination is disproportionate, and accepting the risk ignores continuous contract enforcement.

1. AA passed onboarding check two years ago says little about current posture; accepting without review ignores ongoing risk.
2. BCorrect: third-party risk is managed continuously, through SLA monitoring and periodic posture reviews, not a one-time check.
3. CRepeating the full onboarding is heavy and still point-in-time; continuous monitoring scales better.
4. DDictating the vendor's architecture overreacts to a minor degradation and is outside normal vendor-risk practice.

More below: why each option is right or wrong — scroll this panel

Using verbal or informal approvals for high-impact changes violates governance; administrators must require documented change records and authorization before proceeding. This ensures accountability and risk evaluation even during emergencies.

1. AApplying an untested fix on verbal orders skips authorisation and risk review, even during an outage.
2. BA second verbal approval is still undocumented; governance needs a recorded change and formal authorisation.
3. CCorrect: even emergency changes need a documented record and authorised approval, which the emergency change path provides quickly.
4. DWaiting for the scheduled window ignores the emergency change path that exists for urgent fixes.

More below: why each option is right or wrong — scroll this panel

Tailoring actions, such as altering a password length parameter from a baseline, are permissible if justified. However, failing to record these tailoring actions and the associated parameter values causes ambiguity during assessments. Auditors cannot determine if the deviation is an accepted risk or a misconfiguration, leading directly to an audit or compliance failure rather than immediate technical exploits or algorithmic invalidation.

1. ACorrect: an undocumented deviation from the baseline leaves assessors unable to tell accepted risk from misconfiguration, so it becomes a compliance finding.
2. BNothing forces the service to be disabled; the issue is missing approval and documentation.
3. CA different length is not automatically critical; the impact is the unapproved, undocumented deviation.
4. DNo such automatic rollback exists; the result is an audit finding.

More below: why each option is right or wrong — scroll this panel

Without escort policies, temporary badge holders can wander freely, posing a threat to secure areas. Enforcing escorts mitigates this. Background checks for deliveries are impractical. Smart cards for a guest network address logical access. Retaining logs aids auditability, not immediate physical security.

1. AGuest network security is logical access, not physical movement.
2. BEncrypting logs helps record keeping, not the physical risk of visitors roaming.
3. CBackground checks for every delivery are impractical and matter less than controlling where visitors go.
4. DCorrect: badges identify visitors but do not restrict them; without escorts, visitors can roam into secure areas.

More below: why each option is right or wrong — scroll this panel

Failing to link automated baseline artifacts to the System Security Plan (SSP) creates a disconnect between technical implementation and compliance evidence, making verification impossible. The failure is administrative documentation. Missing penetration tests, outdated encryption, and missing vulnerability scans represent technical control failures, not administrative oversights. While missing RBAC is a control gap, failing to provide the SSP evidence directly prevents auditors from validating the successfully automated secure deployments.

1. ACorrect: the builds may be flawless, but auditors need the baselines tied to the system security plan as evidence; without that link compliance cannot be shown.
2. BNothing suggests weak encryption; the pipeline enforces approved configurations.
3. CAccess control is a separate control; the scenario points to missing compliance evidence.
4. DPenetration tests do not link automated baselines to compliance documentation.

More below: why each option is right or wrong — scroll this panel

Effective metrics map to control objectives. For patch management, core objectives are coverage and speed. Percentage of compliant assets measures coverage, while mean time to remediate (MTTR) critical flaws measures speed.

1. ADownloads and scan frequency measure activity, not whether systems are actually patched.
2. BCorrect: the share of compliant assets measures coverage and mean time to remediate measures speed, the two goals of patch management.
3. CLogin ratios and bandwidth are unrelated to patching outcomes.
4. DReboots and update-server uptime describe operations, not patch effectiveness.

More below: why each option is right or wrong — scroll this panel

For cloud or third-party-hosted assets, organizations must ensure contractual visibility and include required metadata in the inventory. Without detailed supply chain metadata, the security team cannot quickly identify if a third-party SaaS provider uses the vulnerable component, severely delaying incident response capabilities.

1. ACorrect: without software composition and supplier data (an SBOM), the team cannot tell which assets include the vulnerable component.
2. BMonitoring access problems would blind detection, but the issue here is knowing which components exist.
3. CScanners may miss hosted assets, but the root gap is component data in the inventory.
4. DEncrypting the inventory protects it but does not add the missing component data.

More below: why each option is right or wrong — scroll this panel

Translating policy requirements into automated baseline implementations (e.g., IaC templates) directly prevents human-error by standardizing deployments. Mandatory peer reviews and access restrictions fail to eliminate the manual, error-prone nature of the process. Increasing scanning frequency and revising incident response plans are reactive measures that only address misconfigurations after they occur, rather than preventing inconsistent deployments at the source.

1. AMore scanning finds misconfigurations after the fact but does not stop them.
2. BPeer review still relies on manual steps and human attention.
3. CResponse plans deal with the aftermath, not the root cause.
4. DCorrect: infrastructure-as-code templates bake the hardening baseline into every deployment, removing the manual step where errors happen.

More below: why each option is right or wrong — scroll this panel

Controls are classified by their implementation scope. Organizational or common controls (like physical perimeter security) are provided centrally and inherited by multiple systems. Hybrid controls involve shared responsibilities. Since the custom database encryption mechanism is unique to and implemented solely for the new payroll application, it is classified as a system-specific control.

1. ACommon controls are provided centrally to many systems; this one is built just for payroll.
2. BOnly the physical perimeter is inherited here, not the database encryption.
3. CCorrect: encryption built and run for this application alone is a system-specific control.
4. DHybrid controls are partly inherited and partly local; this encryption is entirely local.

More below: why each option is right or wrong — scroll this panel

In a hybrid or shared responsibility model, controls are split between the organization and the service provider. Gaps often occur when the exact boundary of responsibility is ambiguous. To prevent these gaps or duplicated efforts, stakeholders must clearly define, split, and document who is responsible for each specific part of the control (e.g., the provider generates the logs, but the client monitors them).

1. AShifting everything to the provider leaves the customer's part of monitoring undone.
2. BCorrect: hybrid controls fail at unclear boundaries; documenting who owns each part of logging closes the gap.
3. CDuplicate tools add cost and still leave ownership unclear.
4. DThe gap is fixable; accepting it ignores a solvable responsibility problem.

More below: why each option is right or wrong — scroll this panel

In sensitive internal investigations, following escalation playbooks that preserve privacy, legal requirements, and digital evidence is paramount. Immediate technical remediation or confronting the subject can destroy evidence or tip off the suspect. Suspending access might be premature. Remediation or reimaging destroys necessary forensic evidence. Confrontation violates the structured investigative steps required for strict legal involvement and chain of custody preservation.

1. AReimaging the workstation destroys the evidence the investigation needs.
2. BSuspending access may tip off the subject and should follow the legal and HR guidance in the playbook.
3. CBroad remediation can destroy evidence and alert the subject.
4. DCorrect: sensitive insider cases follow the escalation playbook (legal, HR, privacy) and preserve evidence before any action that could alter it.

More below: why each option is right or wrong — scroll this panel