A CIS benchmark item recommends disabling a protocol that a legacy monitoring system still requires on several switches. The system cannot be replaced this year. What is the appropriate way to handle this item?
Select an answer to reveal the explanation.
Short Explanation
Benchmarks are a guide, not a straitjacket, but you can't just pretend a rule isn't there. When you can't meet an item, you write down why, what you're doing instead and when you'll revisit it. The traps are hiding the gap or breaking the business to look compliant.
Full Explanation
Benchmarks are applied within an organization's operational reality, so some recommendations will conflict with genuine requirements. Good governance handles this with a documented exception: the specific item and affected devices, the business reason, the risk it creates, compensating controls such as restricting the protocol to the monitoring server's address, using its most secure available version, or isolating it on the management network, an accountable owner, and a review or expiry date tied to replacing the legacy system. This keeps the risk visible and managed. Quietly skipping the item and reporting full compliance misrepresents the security posture and undermines the audit's integrity. Applying the item regardless of impact disables a required operational function; hardening that breaks monitoring can create its own risk by blinding operations, and the stem states the dependency cannot be removed this year. Removing the item from the copy given to auditors is concealment, a serious governance failure rather than a technical choice. Exam caveat: compensating controls should reduce the specific risk the benchmark item addresses, not merely add unrelated security. Operational check: confirm the exception is recorded in the risk register with an owner and review date, the compensating ACLs are in place on the affected switches, and the assessment tool reports the item as an approved exception.