Risk Management practice questions

Approve the exception informally by email and revisit it if problems appear.

Why wrong: Informal email approval does not create an auditable record, assign a risk owner, or define the compensating controls that make the exception acceptable. It also lacks a defined expiration or renewal trigger, so the risk becomes open-ended and may be forgotten once the email thread ends. Security governance requires formal, time-limited risk acceptance with management sign-off, not ad-hoc correspondence that provides no accountability if the vendor application is compromised.

Disable all monitoring on the workstations so the application will function normally.

Why wrong: Disabling monitoring removes the organization's ability to detect malicious activity, anomalous behavior, or policy violations on those workstations. This is the opposite of a compensating control; it actually increases the risk profile by eliminating the visibility that would allow incident response teams to identify and contain a compromise. Monitoring controls like EDR, syslog forwarding, and perimeter inspection should remain active even when an exception is granted, and any performance conflicts with legacy software should be resolved through configuration tuning or exclusions rather than wholesale deactivation.

Publish the exception as a permanent guideline so other teams can follow it.

Why wrong: Publishing the exception as a permanent guideline would convert a narrowly scoped, time-limited risk acceptance into a broad standing policy for all teams, without management approval for each instance or a defined sunset date. It also bypasses the requirement to evaluate compensating controls per unique environment, since different teams may have different network postures, threat models, or compliance obligations. Permanent guidelines are for approved security baselines, not for exceptions — which by definition deviate from the baseline and must be reviewed, renewed, and eventually retired.

Business continuity testing, because the team is checking recovery procedures.

Why wrong: Business continuity testing evaluates how well a process recovers during disruption. Reviewing vendor controls before signing a contract is a different activity.

Security awareness training, because the vendor is being taught safe behavior.

Why wrong: Security awareness training is for educating people on secure behavior, such as spotting phishing or handling data. It is not the right term for vendor assessment.

Data classification, because the team is labeling the payroll data type.

Why wrong: Data classification is about categorizing information by sensitivity or handling requirements. It does not describe the process of vetting a new vendor.

Business impact analysis (BIA)

Why wrong: Incorrect. A BIA identifies critical business processes and their dependencies, as well as recovery time objectives. It does not serve as a record of risk acceptance decisions.

Security baseline configuration document

Why wrong: Incorrect. A security baseline defines the minimum security configuration settings for systems. It does not document risk decisions or approvals.

Incident response plan

Why wrong: Incorrect. The incident response plan provides step-by-step procedures for handling security incidents. It is not the appropriate place to record risk acceptance decisions.

Increase retention to keep backups for two years without changing restore testing.

Why wrong: Incorrect because longer retention alone does not prove recoverability. Old backups that are never tested may still fail when restoration is needed.

Move the backup repository onto the same always-mounted file share as production data.

Why wrong: Placing the backup repository on the same always-mounted file share as production data eliminates offline isolation, meaning a ransomware attack or storage failure that corrupts the live share simultaneously destroys the backup set. This directly violates the requirement for a restorable copy within the 4-hour RTO, because no independent recovery source exists. It is tempting because co-location simplifies storage management and reduces network transfer time, and would be correct in a scenario where the RTO is zero and continuous data protection from the live volume is acceptable.

Reduce the number of user permissions on the file server without changing backup design.

Why wrong: Incorrect because access reduction may be good hygiene, but it does not directly improve recovery confidence. The question asks about restore assurance and resilience.

Keep both roles assigned but require a manager to review the batch after payment completes.

Why wrong: Post-payment review is useful for detection, but it does not prevent the same person from creating and approving a fraudulent payment in the first place. The control happens too late to fully address the fraud risk described in the exhibit.

Remove the audit role and let payroll staff self-review their own work to save time.

Why wrong: Deleting the audit role eliminates the only independent check on payroll transactions, not just an efficiency step. Self-review is inherently biased because the person who created or modified records is unlikely to catch their own errors or intentional fraud, so the control becomes cosmetic. Without a separate reviewer, the organization also loses the audit trail needed to demonstrate accountability to regulators and external auditors, making the risk worse, not better.

Use a single shared payroll account so the workflow never pauses for approvals.

Why wrong: Using one shared payroll account collapses all individual identities into a single set of credentials, eliminating non-repudiation and making it impossible to determine who actually approved a payment. Even when the workflow technically includes an approval step, any of several users can act without personal accountability, so the control is bypassed in practice. This also violates least privilege and can obscure the attack source during incident investigation, increasing rather than reducing fraud risk.

Ignore the issue because the impact is low.

Why wrong: A low impact does not make the risk acceptable; the high likelihood creates a meaningful expected loss (likelihood × impact) that must be formally assessed. Ignoring the issue violates risk register discipline and leaves management uninformed, especially since likelihood can also change as the system expands. Even if the impact is modest, recording and evaluating the risk is mandatory for defensible security decisions.

Wait until after production launch to see whether the issue actually occurs.

Why wrong: Waiting until after production launch deliberately extends the exposure window and enlarges the blast radius: more users, more data, and dependency chains that make fixes costlier and subject to stricter change control. If the issue triggers during production, the organization faces incident response, potential downtime, and regulatory consequences rather than a controlled pilot adjustment. The pilot exists to uncover and address such risks before launch, so postponing treatment is a reactive, non-governance approach.

Transfer the risk by moving the pilot to a different business unit.

Why wrong: Moving the pilot to another business unit does not transfer risk in the professional sense—it merely changes the organizational owner while the same threat and vulnerability persist. True risk transfer requires an external party to assume financial liability, typically through insurance, contractual indemnification, or outsourcing with enforceable service-level agreements. Without that, the enterprise risk profile is unchanged, and the receiving unit is exposed to precisely the same technical and operational impact.

Require the supplier to send monthly sales updates to the procurement team.

Why wrong: Requiring monthly sales updates is a business/performance metric, not a security control. It gives procurement financial visibility but provides no insight into the subcontractor's security posture, access privileges, or compliance with your organization's security requirements. Without contractual authority to audit or approve the subcontractor, the new attack surface remains completely unmanaged and unmitigated.

Ask the supplier to place all responsibility for the subcontractor on the customer.

Why wrong: Asking the supplier to shift all responsibility for the subcontractor to the customer is not a control; it is an abdication of due diligence. As the customer, you would lack any contractual relationship, audit rights, or technical oversight of the third party, making you both legally exposed and operationally blind. This approach violates the core third-party risk management principle that you must maintain visibility and enforceable obligations across the entire supply chain.

Disable all vendor access immediately without reviewing the change.

Why wrong: Immediately disabling all vendor access is a disproportionate, reactive response that does not constitute a sustainable risk management control. While termination might be warranted in a critical incident, doing so without first assessing the actual risk of the new subcontractor disrupts operations and creates downtime without reducing long-term exposure. This approach also fails to establish a repeatable process for evaluating future supplier changes, leaving the organization without a proactive framework for supply chain risk.

Escalate the issue to legal because all residual risk must be eliminated.

Why wrong: Residual risk is an expected byproduct of any control implementation; eliminating all risk is neither feasible nor necessary. Escalating to legal is only warranted when specific regulatory or contractual obligations are violated, not as a blanket response to residual exposure. Moreover, legal cannot accept risk on the organization's behalf—that responsibility rests with the risk owner, who must formally document and approve the remaining exposure.

Remove MFA because the remaining risk is already low.

Why wrong: Removing MFA after observing a low residual risk would unilaterally increase the organization's attack surface, undermining the security posture. A low residual risk means the control is working, not that the control is expendable; re-evaluation should occur only if a new risk assessment shows the control is no longer cost-effective or introduces unacceptable friction. The appropriate action is to keep the control and formally accept the small remaining risk, not revert to a weaker state.

Treat the issue as resolved because monitoring alone eliminates all risk.

Why wrong: Monitoring is a detective control that shortens response time and helps contain incidents, but it does not prevent or eliminate the underlying vulnerability. Treating the issue as resolved ignores that a threat event still has a probability of occurrence, and the organization remains exposed to impact. Residual risk persists even with monitoring, so it must be formally identified, documented, and accepted by the risk owner, not simply dismissed.

Install patches manually on each laptop after users report problems.

Why wrong: This approach is inherently reactive and depends on end users to detect issues, which means vulnerabilities can be exploited for weeks or months before anyone notices. Manual per-laptop installation also introduces configuration drift, as each device may receive different updates at different times depending on user reports. Without a centralized patch management system and a known-good baseline, the organization loses visibility into the security posture of its fleet.

Deploy all patches to every laptop immediately with no testing.

Why wrong: Untested mass deployment of all patches to every laptop simultaneously is risky because a single problematic patch can break critical business applications or cause driver conflicts across the entire fleet at once. Security patches are not inherently safe; they can introduce new stability or compatibility issues. A lack of staged rollout means there is no opportunity to validate the patch on a small subset first, potentially leading to widespread operational downtime that outweighs the short-term security benefit.

Wait for annual maintenance windows so all changes happen at once.

Why wrong: Waiting for annual maintenance windows means known vulnerabilities remain unmitigated for up to a year, which is unacceptable for a fleet of 300 laptops and far outside the typical patch cadence. This approach treats patching as a static, once-a-year event rather than an ongoing risk management process, and it fails to account for zero-day exploits and emerging threats. Additionally, bundling all changes into a large annual batch increases the risk of deployment failures and makes troubleshooting more difficult.

Delete the old backup copies to prevent future confusion

Why wrong: Deleting old backup copies after a ransomware event eliminates recovery points and may also destroy digital evidence needed for forensic investigation or legal proceedings. While older backups might contain the malware or be dated, confusion is better addressed through a defined retention policy and clear labeling, not by removing data. The only way to prove reliability is a test restore, so deleting backups does not validate the recovery process and increases the risk of permanent data loss.

Switch to incremental backups only so the next restore is faster

Why wrong: Switching to incremental backups immediately after an incident does nothing to confirm that the current full or synthetic backup can actually be restored, which is the immediate priority. Incremental-only strategies create a dependency chain where every daily difference file must be intact, so a single corrupted or missing incremental can render the entire restore unusable. Instead, you should validate the existing backup media through a test restore and then adjust the backup schedule based on measured recovery time objectives (RTO) and recovery point objectives (RPO), not on an assumption that faster backups equal safer recovery.

Store the backups on the same file server so they are easier to access

Why wrong: Storing backup copies on the same file server as production data violates the 3-2-1 backup rule and exposes those copies to the same ransomware attack vector, since the server's file permissions or credentials may be compromised. If the attacker gains access, they can encrypt or delete both the original files and the backups in one operation, leaving no recovery option. Additionally, local backups are accessible from the server itself, so a successful remote code execution or stored XSS could result in total data loss. Offsite or immutable offline backups are necessary to ensure a safe recovery point.

Delete the reports immediately because the business no longer uses them

Why wrong: Deleting the reports immediately without consulting the retention schedule constitutes spoliation—the destruction of evidence potentially relevant to litigation, audits, or regulatory inquiries. Payroll records frequently have statutory retention periods (e.g., under the Fair Labor Standards Act) that apply regardless of current operational use, and premature deletion can trigger fines, legal sanctions, or adverse inference instructions. A compliant disposition process requires documented authorization and verification that no legal or regulatory hold applies before any physical or logical deletion occurs.

Email the reports to each manager so they can keep their own copy

Why wrong: Emailing the reports to individual managers breaks the chain of custody by creating multiple decentralized copies that lack consistent classification, encryption, and access governance. Each inbox becomes an uncontrolled repository, making it impossible to enforce a single retention period or to uniformly respond to legal holds, while also enlarging the attack surface for data exfiltration and violating privacy principles like data minimization. Informal email copies also defeat future disposal obligations because managers may keep or delete them arbitrarily, creating compliance liability under regulations such as GDPR or the Sarbanes-Oxley Act.

Rename the folder so users do not notice it on the shared drive

Why wrong: Renaming the folder merely changes its label while leaving the underlying records unclassified, ungoverned, and still physically present on a shared drive with existing permissions. This action does not alter the records' retention status, access controls, or audit trail, and it fails to address legal or regulatory discovery requirements. In practice, renaming can mask the records from compliance tools, increase confusion among authorized users, and inadvertently delay a defensible disposition, which is far worse than leaving the original name visible but properly managed.

Accept the risk because the vendor uses strong encryption.

Why wrong: While AES-256 encryption is strong, it does not address the full range of risks, such as the lack of customer-managed keys, the outdated penetration test, or legal/compliance exposure from storing PHI in a non-HIPAA jurisdiction. Accepting the risk based on encryption alone ignores these other critical factors.

Terminate the contract immediately and select a different vendor.

Why wrong: Terminating immediately without further investigation may be an overreaction. The risks identified are notable but do not necessarily indicate that the vendor is in violation of HIPAA or unable to provide adequate security. A more measured approach, such as requesting updated documentation, should be taken first.

Require the vendor to implement customer-managed keys and provide a new penetration test report within 30 days.

Why wrong: While customer-managed keys and current penetration testing are desirable, the vendor may not be able to support customer-managed keys in their product architecture, and requiring implementation within 30 days is likely unrealistic. This option attempts to treat the risk through a technical control that the vendor may not offer, making it less practical than requesting an existing SOC 2 report.

Deny the exception and require the project to use an approved platform that meets the AES-256 requirement.

Why wrong: This is incorrect because if the risk is within the organization's risk appetite and compensating controls are effective, a blanket denial may be overly restrictive and could hinder legitimate business operations. Policy exceptions exist to allow flexibility when risk is acceptable.

Accept the risk and allow the project to proceed without a formal exception.

Why wrong: Accepting the risk and proceeding without a formal exception is incorrect because it bypasses the governance and audit trails required for risk acceptance. Even when risk is within the organizational risk appetite, the decision must be documented through a formal exception process that records the rationale, compensating controls, and a re-review date. Undocumented risk acceptance creates unmonitored residual risk, undermines accountability, and can lead to compliance failures during audits or regulatory inspections. Security program management best practices require that every accepted risk be formally tracked and periodically reassessed to ensure the compensating controls remain effective.

Escalate the request to the chief information officer for a final decision.

Why wrong: This is incorrect because the security manager typically has the authority to approve policy exceptions within the defined risk appetite. Escalation without a clear reason adds unnecessary delay and does not leverage the manager's risk assessment.

Update the policy immediately to allow password-only access for all legacy systems.

Why wrong: Rewriting the entire policy to permit password-only access across all legacy systems is a permanent, blanket control downgrade that affects systems not involved in the current request. It bypasses change management and risk review, destroying the MFA control baseline organization-wide rather than addressing a single documented business need. Policy updates should reflect deliberate decisions with broad stakeholder input—not be used as a quick fix for one exception, and doing so creates a lasting compliance gap.

Have the help desk approve the request informally in the ticket and proceed without further documentation.

Why wrong: An informal ticket note lacks the accountable sign-off of a risk owner, fails to define compensating controls, and provides no expiration or review date. Without formal documentation, auditors and security teams lose the ability to verify that the deviation was risk-assessed, time-limited, and tracked to closure—turning a legitimate temporary need into an uncontrolled security exception. It also leaves the organization vulnerable if a later incident occurs because there is no evidence of governance approval.

Ignore the MFA requirement because the portal is owned by a trusted partner.

Why wrong: Trusting a partner's portal does not transfer the organization's compliance responsibility—the organization remains accountable for protecting its data, regardless of who hosts the application. Ignoring the MFA requirement without a documented risk treatment violates governance principles and potentially contractual obligations, leaving no audit trail of the decision. A justified deviation must still be handled as a formal exception with compensating controls, not dismissed based on trust.

Avoid the risk by shutting down the finance application immediately.

Why wrong: Avoidance would eliminate the vulnerability's exposure by taking the application offline, but that action would also halt a critical business service that the organization has determined must remain available for the next six months. In this scenario, the availability impact of a shutdown exceeds the security impact of the known vulnerability. Compensating controls are preferable because they preserve the service while actively reducing the likelihood or blast radius of an exploit.

Transfer the risk by asking the vendor to guarantee that no incident will occur.

Why wrong: Risk transfer does not mean obtaining a promise of perfect security; it typically shifts the financial impact of a loss to an insurer or a vendor through a contract, yet the actual technical vulnerability remains exploitable. A vendor guarantee cannot prevent an attack or protect the finance application's data, and no vendor will accept unlimited liability. Furthermore, the organization retains responsibility for safeguarding its own assets, so this proposed 'transfer' is neither practical nor effective as a risk treatment.

Accept the risk because any delay in patching is automatically low priority.

Why wrong: Risk acceptance is a formal decision made only after a thorough assessment shows that the residual risk is within the organization's risk appetite, and it must be documented and approved by management. A known vulnerability in a finance application directly affects confidentiality and integrity, so classifying it as automatically low priority just because the patch is delayed is unsound. Without compensating controls or a risk-based justification, unwarranted acceptance leaves the organization exposed to potential financial fraud or data loss, violating security governance principles.

The medium-severity missing patch on the isolated lab VM.

Why wrong: The isolated lab VM has no network access, so although a missing patch is a weakness, the attack surface is limited to physical or local attackers. The medium severity indicates moderate impact, but because the system is not reachable from the network, the likelihood of exploitation is dramatically reduced. Thus, it should not outrank an internet-exposed system with high-severity issues.

The low-severity outdated browser plug-in on the visitor kiosk.

Why wrong: The visitor kiosk is likely a non-administrative, restricted-purpose system, and an outdated browser plug-in is rated low severity, meaning the potential impact is limited. Even if the plug-in has known vulnerabilities, exploitation typically requires user interaction and the kiosk may have software restriction policies. This finding, while worthy of attention, carries far less risk than a default credential on an internet-facing management interface.

All three issues have the same priority because they were found in the same scan cycle.

Why wrong: Prioritizing findings solely because they were found in the same scan cycle ignores the fundamental principles of risk assessment, where likelihood and impact outweigh scan timing. Severity, asset criticality, network exposure, and the presence of compensating controls all vary among the three findings, so they inherently have different urgency. Treating all findings equally could lead to fixing a low-risk issue while a critical internet-facing flaw remains exploitable.

Apply the patch immediately without testing so the system is protected sooner.

Why wrong: Applying a critical patch without testing in a staging environment that mirrors production can introduce unexpected conflicts with existing configurations, custom code, or third-party dependencies, potentially causing an outage far more damaging than the vulnerability being patched. Change management best practice requires validating the patch in a representative environment, confirming rollback procedures, and scheduling the deployment during a maintenance window to control risk. Immediate deployment may temporarily reduce a known risk, but it trades that benefit for unqualified operational risk, which is unacceptable for a critical production application.

Disable logging so the patch process uses fewer resources.

Why wrong: Disabling logging to conserve resources during a patch installation eliminates the very visibility needed to detect and diagnose failures such as failed services, file permission errors, or privilege escalations that can occur during the change. Logs serve as an historical audit trail for change control and security monitoring, providing evidence of what transpired so issues can be traced and reverted efficiently. In practice, patch processes consume negligible resources compared to the value of operational telemetry, and sacrificing that visibility during a sensitive change makes troubleshooting more difficult and slower.

Postpone the patch indefinitely until all business users request it.

Why wrong: Indefinitely postponing a security patch leaves known vulnerabilities exposed to exploitation, which is particularly dangerous for a production application that may hold sensitive data or be internet-facing. Patch decisions should be driven by risk assessment, threat severity, and exploit availability, not by waiting for every business user to explicitly request the update—many users may never voice an opinion, but the organization still bears the risk. A reasonable approach is to schedule patch deployment through a defined change window, communicate the impact in advance, and balance availability needs against the security imperative rather than kicking the decision down the road.

Allow subcontractors without review if the vendor remains responsible

Why wrong: Even if the vendor remains contractually liable, a new subcontractor has its own people, processes, and technology stack that can expose customer data to unvetted risks. Accountability after a breach does not prevent the breach, and the prime vendor may lack direct operational control over the subcontractor's daily security practices. Requiring review and acceptance of subcontractors is the only way to ensure equivalent security controls are contractually flowed down and verified.

Only require a verbal promise that the subcontractor is secure

Why wrong: A verbal assurance is unverifiable and creates no enforceable obligation, making it impossible for the company to audit the subcontractor's controls or demand remediation if security gaps emerge. Without a written commitment specifying required safeguards, data-handling rules, breach notification duties, or audit rights, the company has no contractual lever to enforce accountability. Security assurances must be documented, reviewed, and tied to specific technical requirements to be meaningful in a supply chain risk assessment.

Remove all contract language related to third parties

Why wrong: Deleting third-party language strips away the contractual basis for defining security expectations, data ownership, and liability when a vendor engages external entities. This leaves the company without visibility into changes in the processing ecosystem and without a mechanism to enforce access controls, encryption, or breach reporting on downstream parties. Contract clauses are the primary tool for implementing due diligence and maintaining an accurate software supply chain map, so removing them would directly undermine the third-party risk management program.

Add more workstations to VLAN 10 so authentication requests are faster.

Why wrong: Adding more workstations to VLAN 10 does not address lateral movement; it broadens the trust domain on a segment that already contains sensitive resources. Authentication speed is not a security issue and would be better resolved by improving the authentication infrastructure rather than increasing the number of endpoints on the same VLAN. This change actually enlarges the attack surface an adversary can pivot from after compromising a single user device.

Disable logging on the servers so attackers leave fewer traces if they connect.

Why wrong: Disabling logging on servers provides no security benefit and actively harms the organization's ability to detect a compromise. Attackers are not stopped by the absence of logs; they simply operate without a trail, extending the time to discovery and increasing the damage. Contrary to reducing risks, this action violates security best practices that require robust audit logging to support incident response and forensic investigation.

Move all servers into the same VLAN as the workstations for easier access control.

Why wrong: Consolidating servers and workstations into one VLAN collapses the network segmentation that normally restricts an attacker’s ability to pivot laterally from a compromised workstation to sensitive server resources. This change directly violates the principle of least privilege at the network layer, as it removes the isolation that a separate server VLAN provides. It is tempting because VLANs are commonly used to simplify access control lists and reduce broadcast domains, and in a flat network where all devices share identical trust levels, merging VLANs could streamline management without introducing additional risk.

Ignore the residual risk because the vendor has a current SOC report.

Why wrong: A current SOC report, even a SOC 2 Type II, is only a point-in-time independent assessment of a service organization's controls related to certain trust service criteria. It does not guarantee coverage of the specific gaps identified here, such as the missing custom log export, and it does not eliminate residual risk. The vendor's report provides assurance but cannot substitute for the business owner's formal risk acceptance because the residual risk remains outside the report's scope.

Require the security team to approve the launch verbally so the project does not slow down.

Why wrong: Verbal approval from the security team is not binding and fails the fundamental requirement of risk acceptance, which is to create an auditable, accountable decision by the risk owner. Security staff are not the business owner and cannot formally accept residual risk on their behalf. Without a written record, there is no evidence that the business understood the tradeoff, executed compensating controls, or assumed ongoing ownership, which could lead to unfounded decisions in an audit or incident review.

Cancel the contract immediately because any medium risk rating is unacceptable.

Why wrong: Canceling the contract solely due to a medium residual risk rating ignores the organization's risk appetite and the formal risk decision framework. Medium risk is not inherently unacceptable; it is a trigger to evaluate whether the expected business benefit justifies the residual risk and whether compensating controls reduce exposure to an acceptable level. Immediate termination bypasses the risk acceptance workflow, potentially discarding valuable business functionality over a level of risk that could be formally accepted and documented.