Security Program Management and Oversight practice questions

Asset age and user satisfaction

Why it fails: Asset age and user satisfaction do not quantify likelihood or impact, so they cannot order remediation work. They are tempting because ageing hardware correlates with failure and satisfaction signals service quality, but risk prioritisation requires likelihood and impact values, which these attributes do not provide.

Vendor popularity and implementation speed

Why it fails: Vendor popularity and implementation speed say nothing about likelihood or business impact, so they cannot rank risks for remediation. They are tempting because procurement and rollout planning genuinely weigh vendor adoption and deployment timelines, but prioritisation requires likelihood and impact scores, not supplier metrics.

Encryption algorithm and screen resolution

Why it fails: Encryption algorithm and screen resolution are technical and display attributes, not risk-ranking inputs; neither expresses likelihood or impact. They tempt because cryptographic strength matters in control selection and resolution in endpoint standards, yet the question asks how remediation order is decided, which uses likelihood and impact.

R-101, because manual review means the risk is already partially controlled.

Why it fails: A manual review is a control that should already be reflected in the risk's residual likelihood and impact scores, not treated as a separate reason to defer remediation. In the scoring model shown, priority is determined by the final likelihood-impact score, so a partially controlled risk either has a lower residual score or the control is insufficient to reduce it. R-101 still ranks below R-104, which means its residual risk is lower despite the existing review process. The presence of a control does not override the organization's stated rule of prioritizing the highest scored risk.

R-102, because a cheaper remediation always has priority over a higher total score.

Why it fails: Remediation cost is a resource consideration, but the exhibit explicitly states that the organization sets priority using the likelihood-impact score, not a cost-benefit ratio. A cheaper fix for a lower-scoring risk might be attractive from a budget perspective, but it would violate the defined prioritization model and leave the highest remaining risk untreated. Unless two risks are tied or the register includes a separate cost-priority column, cost cannot override the scoring matrix. Therefore, R-102, with its lower total score, would not be selected over R-104.

R-103, because critical impact always outweighs likelihood in the matrix.

Why it fails: In a risk matrix that multiplies likelihood and impact, a critical impact (e.g., 5) paired with a low likelihood (e.g., 2) yields a score of 10, whereas R-104's score of 16 suggests a higher combined total. The organization uses the numeric product (or sum), so impact alone is not the deciding factor; likelihood is weighted equally in the stated model. Claiming critical impact always dominates ignores the matrix's intended balancing of probability and consequence. Thus, R-103 cannot be prioritized based solely on its high impact when its overall score is lower than R-104.

Inherent risk: The level of risk after controls are applied

Why it fails: This statement is incorrect because it reverses the temporal relationship between controls and risk. Risk measured after controls have been applied is residual risk, while inherent risk is only meaningful as the pre-control baseline. Using this incorrect definition would make it impossible to quantify control effectiveness or to justify additional investment in mitigation, since the true starting point would be unknown.

Risk appetite: The acceptable deviation from the risk appetite

Why it fails: This statement incorrectly assigns the definition of risk tolerance to risk appetite. Risk appetite is the overarching inclination to accept risk, while tolerance is the permissible variation around that appetite for a specific exposure. Failing to distinguish them can lead to either too-stringent operational limits without strategic intent, or strategic statements without actionable thresholds.

Allow the supplier to choose any encryption algorithm it wants.

Why it fails: Permitting the supplier to freely choose any encryption algorithm abdicates the organization's responsibility for cryptographic standards and risks adoption of outdated or non-compliant algorithms, such as DES or RC4. This weakens security because the organization cannot mandate strong options like AES-256 or proper key management, and it eliminates any chance of validating that the supplier meets regulatory requirements. This option is a delegation of control, not an improvement in oversight.

Disable all contract reviews after signature.

Why it fails: Disabling contract reviews removes the organization's ability to monitor the supplier's evolving security posture, including flagging material changes like new subcontractors or weakened controls. It turns the contract into a static document with no continuous oversight, directly contradicting the goal of supply chain risk management. This action increases risk by leaving unknown vulnerabilities undiscovered until after a breach.

Require the vendor to use employee badges for all facilities.

Why it fails: Requiring employee badges addresses physical access control at the vendor's facilities but does little to secure data processing, network segmentation, or subcontractor handling. The exhibit's missing control is a contractual/administrative mechanism like an audit right, not a physical safety measure, so badges fail to provide the necessary verification of security operations. Even with badges, the organization cannot inspect evidence of compliance or validate third-party risk.

A screenshot of the firewall's current rule base after the change.

Why it fails: A screenshot of the firewall's current rule base only depicts the resulting configuration at a single point in time; it carries no metadata about who requested or authorized the change, nor when that approval occurred. It could even be captured from an unapproved modification, and it does not demonstrate that a formal review preceded implementation. As a static snapshot, it lacks the procedural and chronological evidence required to satisfy an auditor's request for change-control verification.

A technician's memory of getting permission over the phone.

Why it fails: Reliance on a technician's recollection of a phone conversation is inherently unreliable because memory is fallible, easily interpreted through bias, and vulnerable to post hoc rationalization. An auditor cannot independently verify the exact content, timing, or authority of the verbal approval, and no durable record exists to support the narrative. Evidence must be objective, reproducible, and immutable; oral testimony alone lacks these qualities and is therefore inadmissible as proof in most formal audits.

The organization's general information security policy.

Why it fails: An information security policy is a directive that establishes the rules and standards for change management, but it is not a record of any specific action having been taken. It cannot demonstrate that the particular firewall change was submitted, reviewed, or approved per the required process. Auditors require evidence of execution—such as approved tickets or CAB records—not just the existence of a governing document that merely mandates the procedure.

Require every employee to attend a full-day annual course this week

Why it fails: Requiring a full-day annual course this week is an overreaction that sacrifices a day of business productivity for every employee, not just those who clicked, and it separates the training content from the specific simulation that exposed the weakness. The delay also means corrective information is not delivered during the acute window when users are most likely to integrate the lesson, reducing training transfer. Additionally, long, mandatory training sessions are known to induce cognitive fatigue, which can actually lower retention and engagement compared to brief, focused, repeated messages.

Publicly post the names of employees who clicked the simulation

Why it fails: Publicly posting the names of employees who clicked the simulation is an example of negative incentives that backfire in security awareness. It creates a punitive environment where users fear embarrassment or disciplinary action, which strongly suppresses the reporting of both simulated and real phishing attempts, precisely the behavior you need to encourage. It also risks violating workplace privacy norms and can lead to resentment of the security team, ultimately undermining the foundation of trust that is essential for a successful security program.

Disable all email attachments for every user

Why it fails: Disabling all email attachments for every user is a technically extreme and operationally crippling control that takes precedence over system usability and business processes. It removes a critical communication channel used for contracts, invoices, and collaborative documents, forcing workarounds that often carry greater risk, such as users sending sensitive data via less secure channels. Rather than solving the root cause of user susceptibility, it abandons education and awareness in favor of a blunt access restriction that cannot be justified in a risk-based security program.

Disable email for all staff until phishing activity stops.

Why it fails: Disabling email for all staff until phishing activity stops is operationally disruptive and unrealistic, as email is the primary communication backbone for most organizations. Phishing activity cannot be completely stopped, so the 'until' condition may never be met, leading to indefinite downtime. This approach punishes the entire workforce and encourages risky workarounds like personal email or unmanaged file-sharing, which can introduce greater security risks. It fails to address the root cause: user susceptibility to social engineering.

Block all external senders permanently.

Why it fails: A permanent block on all external senders would sever communication with customers, vendors, and partners, causing severe business continuity damage. Legitimate external emails are essential for operations, and a blanket block would also prevent receiving security advisories, customer inquiries, and other critical correspondence. This measure does not mitigate internal phishing, account takeover, or malicious attachments from trusted compromised senders, and it ignores the need for layered, risk-based email defenses.

Finding 2, because any default setting should always outrank all other issues automatically.

Why it fails: Finding 2 is wrong because default settings, while important, should never automatically outrank all other issues without considering context. This internal wiki is low impact and has low exploitability, as it is not internet-facing and likely contains no sensitive data; thus, its risk is limited compared to findings with remote attack vectors or critical business data. Prioritizing it solely on the existence of a default configuration would ignore the actual likelihood and impact that drive risk management.

Finding 5, because any outdated software should be fixed before higher-impact business systems.

Why it fails: Finding 5 is wrong because outdated software alone does not justify priority; the lab VM is isolated and has low business impact, meaning the likelihood of exploitation is minimal and the blast radius is tiny. The age or patch level of software is just one factor, and without internet accessibility or critical data, this finding poses far less risk than the customer portal, which is both remotely accessible and tied to administrative functions. Effective risk prioritization weighs business impact, exploitability, and exposure—not simply whether a component is outdated.

An internal lab system with an outdated browser component, isolated from production and not customer-facing.

Why it fails: An internal lab system with an outdated browser component is a low-priority risk because it is isolated from production and not accessible from the customer-facing network, which severely limits the attack surface. An attacker would first need to gain a foothold in the internal network, significantly reducing the likelihood of exploitation. The system's lower business impact, due to its segregated role and lack of sensitive data, further lowers its risk score. While the outdated browser could theoretically be a launch point for lateral movement, the compensating control of isolation and its non-critical function make it acceptable to defer until a routine patching cycle.

A training virtual machine used offline once per month in a disconnected lab.

Why it fails: A training virtual machine used offline once per month in a disconnected lab presents minimal risk because it lacks network connectivity, eliminating remote attack vectors entirely. An attacker would need physical access to the lab environment, which is typically controlled and monitored, making exploitation highly improbable. The VM does not contain production data or interact with corporate systems, so the business impact of a compromise is negligible. Consequently, while the lack of updates might be a hygiene issue, the practical risk is so low that it should be deprioritized in favor of addressing exploitable, externally facing vulnerabilities.

A documentation site with a spelling error in its banner text.

Why it fails: A documentation site with a spelling error in its banner text is not a security vulnerability at all; it is purely a cosmetic issue that does not affect confidentiality, integrity, or availability. Spelling errors do not introduce any attack vector, weaken authentication, or expose sensitive data. From a security risk assessment perspective, this finding has zero practical impact on the organization's security posture. While it might be worth fixing for professionalism, it should not consume resources from remediating actual exploitable flaws that could lead to data breaches or system compromise.

Users should consider keeping their devices updated whenever convenient.

Why it fails: The phrase 'should consider' is advisory and non-normative, placing the decision to update in the hands of the user rather than establishing a mandatory baseline. Standards require imperative language such as 'must' or 'shall' to create enforceable obligations, and this statement lacks any defined update timeliness or technical enforcement mechanism. As a result, it cannot be audited or verified through system configuration checks, making it a guideline rather than a standard. This vagueness would lead to inconsistent security posture across devices.

Employees must follow the company's acceptable use policy at all times.

Why it fails: While this is a mandatory-sounding rule, 'acceptable use policy' is a broad organizational directive that governs human behavior, including internet browsing, email, and data handling, without specifying technical thresholds. It cannot be directly enforced through configuration settings or verified via system audits because it relies on user discretion and interpretation. Such high-level guidance belongs at the policy tier, above standards that must provide exact, measurable requirements like encryption algorithms or session timeouts. Therefore, it does not qualify as a technical baseline standard.

An internal training VM used by one student with a medium vulnerability and no sensitive data

Why it fails: This VM is isolated from production traffic, reachable only by a single student, and contains no sensitive data, which minimizes both the likelihood of a meaningful attack and the business impact if compromised. A medium-severity issue on an internal training system does not usually lead to data loss, financial damage, or lateral movement into critical systems. While it should be patched eventually, it does not warrant intervention this week compared to production-facing risks.

A discontinued server already removed from the network but still listed in inventory

Why it fails: This server has already been physically and logically disconnected from the network, so it poses no active or reachable security risk; an attacker cannot exploit a system that is not connected. The main concern is inventory hygiene and the risk that a ghost asset could accidentally be reconnected without proper hardening, but that is a documentation problem, not a current vulnerability. Therefore, this finding is significantly less urgent than active production systems with known exposures.

A low-severity cosmetic issue on a noncritical dashboard page

Why it fails: A low-severity cosmetic issue on a noncritical dashboard page has no direct impact on confidentiality, integrity, or availability, and it does not provide any path for unauthorized access or privilege escalation. Such a flaw might affect user experience or interface appearance but does not expose sensitive data or allow malicious code execution. Since it creates no meaningful security risk, it should be deprioritized in favor of findings that could lead to a real breach.

Verify that no legal hold or regulatory exception applies.

Why it fails: Before any disposal, you must verify that no active legal hold, pending litigation, or regulatory investigation requires the forms to be preserved. A legal hold overrides normal retention schedules, and destroying records subject to a hold can result in severe discovery sanctions, spoliation claims, and adverse inferences in court. This check ensures that the destruction is both lawful and defensible.

Store the forms in a desk drawer for another quarter just in case.

Why it fails: Storing expired forms in a desk drawer 'just in case' is an ad hoc action that deviates from the approved records schedule and introduces unnecessary risk. These unofficial caches often lack the access controls, environmental safeguards, and indexing of a compliant records management system, making them vulnerable to unauthorized viewing, theft, or misfiling. Keeping expired records without a documented business or legal need also violates minimum retention principles.

Email scans of the forms to managers so they can keep a copy.

Why it fails: Emailing scans of the forms to managers creates redundant digital copies in enterprise email systems and mailboxes, which may be backed up, archived, or synced to cloud services indefinitely. This broadens the attack surface and increases the chance of a data breach, since email is rarely an approved secure storage mechanism for personal information. It also contradicts the core objective of secure disposal, which requires that no copies survive after the retention period ends.

Reply to the sender and ask them to prove they are legitimate

Why it fails: Replying to the sender to ask for proof of legitimacy is counterproductive because any response—even a skeptic's challenge—confirms that your phone number is actively monitored by a human or auto-responder. This validation marks your number as a 'live target,' increasing your likelihood of receiving follow-up attacks with more personalized social engineering lures. Additionally, the sender may use your reply to extract behavioral cues or to build a profile for a spear-phishing campaign against you or your colleagues.

Enter the code to see whether the message is real

Why it fails: Entering the code to test the message's authenticity is dangerous because the one-time code is likely the MFA token for your corporate account. Submitting it into any web form or replying with it gives the attacker a real-time valid token, which they can immediately use to authenticate as you before the code expires. Even if the account seems inaccessible or the portal looks suspicious, entering the code might still be enough to complete the attacker's session hijack, so you must never use the code as a diagnostic tool.

Forward the text to coworkers so they can compare it

Why it fails: Forwarding the text to coworkers so they can compare it amplifies the risk rather than mitigating it. The forwarded message may be treated as a legitimate warning, prompting others to tap the link or answer the sender, directly expanding the attack's reach and potential victim count. Additionally, forwarding does not provide the security team with the metadata or headers needed for investigation, and it can normalize the behavior of interacting with unsolicited messages instead of following proper reporting procedures.

Move the forms to an unsecured archive so they can be retrieved later if needed.

Why it fails: Moving paper forms to an unsecured archive fails every records-management control: it provides no access restrictions, no environmental protections, and no audit trail for who can retrieve or view the documents. Because the forms contain personal identifiable information (PII), an unsecured archive increases the risk of unauthorized disclosure and data breaches. This action also does not satisfy secure disposal requirements because the records remain intact and retrievable.

Keep personal copies because auditors might ask informally later.

Why it fails: Keeping personal copies for potential informal auditor questions bypasses the formal records-management process and creates an untracked, uncontrolled copy of sensitive data. This violates the principle of least privilege and expands the organization's attack surface, because personal files are rarely protected by enterprise security controls like encryption or access monitoring. It also undermines compliance audits by making it impossible to demonstrate that records were disposed of consistently per policy.

Policy

Why it fails: A policy states intent and high-level direction, but it is usually less specific than mandated technical settings.

Procedure

Why it fails: A procedure describes step-by-step actions to accomplish a task, not the required security posture itself.

Guideline

Why it fails: A guideline is recommended rather than mandatory, so it would not fit a compliance-enforced requirement.

Policy

Why it fails: A policy is a high-level directive that communicates management's intent and overall security goals, such as 'all laptops must be secured.' It deliberately avoids prescribing specific technical settings, because those details belong in lower-level documents. Policies are mandatory in tone but leave room for implementation choices, so they do not define the exact minimum security configuration.

Procedure

Why it fails: A procedure is a sequential, step-by-step set of instructions that describes how to perform a specific task, such as how to apply a security patch or how to configure a laptop. It assumes a particular standard or policy already exists and focuses on the order of operations, not on defining the minimum technical requirements themselves. Therefore, a procedure cannot serve as the document that specifies required laptop security settings.

Guideline

Why it fails: A guideline is a recommended, non-mandatory set of best practices that offers flexibility in implementation. It may suggest possible security settings but explicitly allows for exceptions or alternative controls based on situational judgment. Because guidelines are advisory rather than required, they cannot enforce that all laptops meet a minimum security baseline, which is the manager's goal.

Policy

Why it fails: A policy states broad management intent and rules, but it usually does not define the specific required settings.

Procedure

Why it fails: A procedure explains the step-by-step method for completing a task, not the mandatory security posture itself.

Guideline

Why it fails: A guideline is recommended but optional, so it would not be the right choice for mandatory controls.

Send a company-wide reminder to never click links in email, regardless of sender.

Why it fails: A company-wide reminder treats phishing as a simple binary 'do not click' rule, which fails against attacker techniques like display-name spoofing and lookalike domains that mimic legitimate senders. It also provides no concrete workflow for verification or reporting, and because the exhibit shows repeated role-specific lure patterns, a generic email will soon be ignored or forgotten. Without teaching users to inspect URLs, verify via out-of-band channels, or report suspicious messages, this measure offers only a false sense of security.

Focus only on punitive action for users who failed the simulation.

Why it fails: Punitive action for simulation failures creates a climate of fear and blame, which discourages users from reporting real phishing attempts because they worry about disciplinary consequences for clicking a legitimate-looking link. It also does nothing to address the underlying susceptibility to job-themed lures that the exhibit highlights; employees who clicked are simply penalized rather than taught to recognize red flags like urgency, mismatched domains, or unusual requests. This approach reduces incident visibility for the security team, as users will hide mistakes instead of sending suspicious emails to the SOC for analysis, ultimately increasing organizational risk.

Run the same broad awareness module again for all employees at the same time.

Why it fails: Re-running the same broad awareness module for all employees in a single mass deployment ignores the exhibit's evidence that different departments respond differently to tailored phishing lures, such as finance receiving invoice-based bait and IT receiving credential-reuse bait. A generic, one-size-fits-all session does not align with each role's real threat model, and scheduling it for everyone at the same time prevents the security team from measuring which departments improve under specific training. It also lacks recurring, interval-based reinforcement and built-in reporting practice, so any short-term knowledge gain will decay without retention checks or measurable indicators like click rates and report rates over time.

Upload the file to a personal cloud account

Why it fails: Uploading the file to a personal cloud account, such as a consumer Dropbox or Google Drive, removes the data from the organization's tenant and places it outside the reach of corporate security policies, audit logging, and retention schedules. Even if the data is encrypted during transfer, the file remains at rest on third-party servers with no contractual guarantees of confidentiality or jurisdictional compliance, exposing employee PII and salary information to unauthorized access or legal disclosure without the organization's knowledge.

Remove the salary columns and send the rest by email

Why it fails: Removing the salary columns leaves the employee names, which are personally identifiable information (PII) and may be regulated under privacy laws such as GDPR or CCPA. Moreover, email is not an inherently secure channel; it can be forwarded accidentally, intercepted during transmission, or stored indefinitely on mail servers without the necessary encryption, and the redaction process itself does not sanitize metadata or hidden worksheet data that could still reveal salary information.

Print the file and leave it on a shared desk

Why it fails: Printing the spreadsheet and leaving it on a shared desk bypasses all technical security controls; the paper copy is unencrypted, lacks an access control list, and cannot be audited. It is susceptible to shoulder surfing, theft, or being picked up by unauthorized personnel, and even if later shredded, the immediate exposure on the desk violates confidentiality principles and can result in a physical data breach of employee salary information.

Ask the vendor to provide a color logo and updated marketing brochure for the pilot.

Why it fails: Requesting a color logo and an updated marketing brochure is a purely cosmetic branding exercise that has zero influence on the vendor's obligation to notify the organization of a security incident or to permit security reviews. Such materials cannot impose a legal duty, establish a timeframe for reporting, or give the organization any right to verify the vendor's security posture, so they leave the identified contract risk completely unaddressed. This option is nonresponsive because it treats a third-party risk management problem as a communications task.

Allow the vendor to start first and decide later whether to add security terms.

Why it fails: Allowing the vendor to begin the pilot before security terms are finalized forfeits the organization's primary leverage: the vendor has little incentive to accept restrictive notification or audit clauses once the engagement is already underway. Without a signed contract, the organization also lacks a clear legal basis to compel the vendor to provide incident details, preserve evidence, or allow an independent security review, making post-onset negotiation likely to yield weak or ambiguous terms. Starting service first and writing security later effectively accepts the current contract gap while surrendering the negotiating position needed to close it.

Replace the pilot with a purely internal spreadsheet process to avoid any contract review.

Why it fails: Replacing the vendor pilot with an internal spreadsheet process may reduce exposure to third-party threats, but it sidesteps the question asked: how to improve the organization's contractual ability to respond to a vendor compromise. This option does not add any breach notification or review rights to a contract, and in many cases, internally re-creating the vendor's service is infeasible, costly, or less secure than a well-vetted partner with an enforceable security clause. The exhibit highlights a gap in the vendor agreement, not a need to abandon the pilot, so the correct response is to strengthen the contract, not to bypass it.