Baseline Tailoring Under a Tight Budget
A Moderate-baseline system supporting a grants-management mission must be assessed in 90 days. The security team has 1,200 labor hours available and estimates full implementation of the baseline at 2,600 hours. The system owner proposes scoping out 40% of the baseline controls, including several audit-logging and configuration-management controls, arguing that the system is 'cloud-hosted, so the provider handles it.' The cloud provider's shared-responsibility matrix shows the provider handles physical and infrastructure controls but the agency retains responsibility for identity management, logging configuration, and application-level access control. The authorizing official has previously rejected scoping proposals that lacked a documented rationale. A recent internal audit found three unresolved findings related to excessive privileged access.
1. Assess the proposed 40% scoping. Which parts are defensible and which are not, and how should the team proceed given the 90-day and 1,200-hour constraints?
Read the worked answer
Blanket scoping of 40% is not defensible. The cloud-provider argument only supports scoping controls the provider demonstrably implements - physical security, hypervisor and infrastructure hardening, and facility controls - and even then the agency must retain inherited-control documentation and verify the provider's evidence. Audit logging, configuration management, identity management, and application access control sit squarely on the agency side of the shared-responsibility matrix, so scoping them out would leave the system unprotected in exactly the areas where the internal audit already found excessive privileged access.
The defensible path is tailoring, not wholesale scoping: (1) mark genuinely inherited controls as inherited with provider evidence cited; (2) apply scoping criteria to controls that are truly not applicable to the technology or mission, documenting each; (3) for the remaining gap between 1,200 and 2,600 hours, use compensating controls and risk-based prioritization rather than deletion - prioritize the privileged-access and logging controls flagged by audit; (4) record accepted risk for anything deferred, with the authorizing official's explicit concurrence. The 90-day clock argues for phased implementation with an interim authorization-to-operate or a documented plan of action and milestones covering deferred items.
2. The system owner wants to defer the audit-logging controls to save 300 hours. What reasoning should the security lead present, and what alternative satisfies both the budget and the audit findings?
Read the worked answer
The security lead should argue that audit logging is among the least appropriate controls to defer on this system. Three unresolved findings concern excessive privileged access; logging and log review are the primary detective mechanism for privileged misuse. Deferring them removes the ability to detect the very risk the audit already confirmed, converting a known finding into an unmonitored exposure. The 300-hour saving also likely understates the cost, because logging configuration is a prerequisite for several monitoring controls, so deferral cascades.
A better alternative: implement centralized logging with a managed or provider-native service to reduce labor, scope initial log review to privileged and authentication events rather than all events, and automate alerting for high-risk patterns. This can plausibly fit within 100–150 hours instead of 300. Pair it with a plan of action and milestones for the broader logging program, and present the authorizing official with a risk-acceptance memo for any residual deferral. The framing should be: we are not choosing between logging and budget; we are choosing between targeted, automated logging now and an unbounded exposure that the audit has already flagged.