SY0-701 Security Program Management and Oversight Practice Question
A developer requests a 45-day exception to use an unsupported browser plug-in on two engineering workstations so a legacy design tool can finish a customer deliverable. Which three conditions should be required before approving the exception? Select three.
⚠ Common exam trap
The trap here is that candidates may mistakenly think converting an exception to a permanent waiver reduces administrative overhead, but CompTIA emphasizes that exceptions must remain temporary and reviewed, as permanent waivers bypass the risk management process and can lead to unmanaged security gaps.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Document a business justification that explains why the plug-in is required for the deliverable.
Documenting a business justification provides a formal record of why the exception is necessary, ensuring that the risk of using an unsupported browser plug-in is understood and accepted by management. This aligns with the principle of risk acceptance, where the business need outweighs the security risk for a limited time. Without a clear justification, the exception could be granted without proper oversight, potentially leading to unchecked vulnerabilities.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Document a business justification that explains why the plug-in is required for the deliverable.
Why this is correct
Documenting a business justification is correct because it ties the use of an unsupported plug-in directly to a concrete deliverable, proving that the accepted risk serves a legitimate operational need rather than administrative convenience. This artifact gives the risk owner clear evidence to make an informed decision and creates an audit trail explaining why the standard security baseline could not be met. The justification should name the deliverable, the plug-in's required function, and the impact of not using it, making the exception defensible during review.
- ✗
Convert the exception into a permanent waiver to avoid repeated review overhead.
Why it's wrong here
Converting a temporary exception into a permanent waiver is wrong because it eliminates the planned risk review and treats a temporary deviation as a new baseline, which defeats the purpose of exception management. A permanent waiver also hides the unsupported plug-in's changing version, patch, or compatibility status, so the organization loses the trigger that would force a reassessment when risk levels shift. Exceptions are intentionally time-bound to ensure that risks are re-evaluated against current threats and the plug-in's evolving security posture.
- ✓
Set a defined end date and require review before the exception expires.
Why this is correct
Setting a defined end date and requiring a review before expiry is correct because it establishes a formal reassessment point where the plug-in's current vulnerability status, the deliverable's progress, and any new mitigations must be revalidated. This time-bounding converts the exception from an open-ended permission into a controlled, accountable risk acceptance, preventing the exception from silently continuing beyond the original 45 days. The review should confirm that the business justification still holds and that compensating controls remain effective or should be adjusted.
- ✓
Apply compensating controls, such as host isolation, restricted user access, or limiting use to named workstations.
Why this is correct
Applying compensating controls such as host isolation, restricted user access, or limiting the plug-in to named workstations is correct because these measures reduce the attack surface and the exploitability of the unsupported software while it remains in use. Network segmentation and least privilege help prevent a plug-in vulnerability from becoming a foothold for lateral movement, offsetting the lack of vendor patches or official support. The controls must be actively enforced and verified rather than merely documented, because an exception without operational mitigation is just an unmanaged risk.
- ✗
Allow the requestor to self-approve the exception if the project deadline is urgent.
Why it's wrong here
Allowing the requestor to self-approve the exception is wrong because it removes the independent review that verifies the exception is justified and that the risk has been analyzed by someone other than the person with a direct interest in approval. Urgency is not a security control; it can bias the decision and obscure the fact that the unsupported plug-in may have known vulnerabilities with no available patch. A valid exception process requires a designated authority or risk owner to evaluate the request because the developer needing the deliverable has an inherent conflict of interest in obtaining the exception.
Go deeper
Related to this question
Learn chapter
Risk Management Concepts
Key term
Risk acceptance
Risk acceptance is a risk management strategy where an organization acknowledges a potential risk but decides to tolerate it without taking active measures to reduce or eliminate it.
Key term
Risk
Risk is the possibility that an event or action will negatively affect an organization's ability to achieve its goals, often measured in terms of likelihood and impact.
About these practice questions
One of 1,013 original SY0-701 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on SY0-701
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. An engineering team requests a 30-day exception to use an unsupported browser plug-in on two workstations so a customer deliverable can be finished. Security agrees the business need is legitimate, but wants to reduce exposure. What must be included before the exception is approved?
medium- A.A verbal approval from the engineering manager and no additional documentation.
- ✓ B.A documented exception with an end date, compensating controls, and approval by the risk owner.
- C.A standing waiver that remains in place until the project finishes, with no review date.
- D.A guideline reminding the team to avoid risky behavior when practical.
Why B: A documented exception with a defined end date, compensating controls, and risk-owner approval is the correct approach. Security exceptions should be controlled, reviewable, and temporary whenever possible. That structure shows the business need was acknowledged while ensuring someone has formally accepted the residual risk and the organization can reassess the exception before it becomes indefinite. Why others are wrong: A verbal approval is not enough for auditability or accountability. A standing waiver without a review date can quietly become permanent and increase exposure. A guideline does not authorize deviation from policy or provide the controls required for an exception process. The question is about formal exception handling, not informal advice.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SY0-701 practice question is part of Courseiva's free CompTIA certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SY0-701 exam.