A compliance lead scopes a statewide privacy policy to every configuration item in the CMDB, including printers and unused lab PCs. What is the main problem with that entity scope?
Select an answer to reveal the explanation.
Short Explanation
Think of watering every plant on the block when only the vegetable garden needs it — you drown the roses and still miss the tomatoes. If privacy controls hit every printer and forgotten lab PC, testers drown in noise and never prove the systems that actually touch personal data. Scope entities to where the obligation lives.
Full Explanation
Entity scope should reflect where a policy or obligation meaningfully applies. Scoping a statewide privacy policy to every CMDB CI—including printers and unused lab PCs—creates noisy, low-value control tests across objects that do not meaningfully handle personal data. Testers drown in volume while systems that actually process PII may still lack attention, producing false confidence through coverage theater. Narrow, relevant populations for applications and services that store or process personal data keep evidence useful for civic privacy programs. Claiming narrowing always violates statewide privacy statutes so every CI must stay included confuses legal applicability with unfiltered CMDB dumps. Saying printers must be entities because Policy and Compliance cannot link controls to applications alone is false and drives noise. Claiming entity scoping is only for risk statements so privacy policies should ignore CMDB records entirely denies policy-to-entity association. Exam caveat: over-broad scoping is a recognized anti-pattern; scope to where the obligation lives. Operational check for the compliance lead: define inclusion criteria for privacy-relevant applications and data stores, exclude endpoints that cannot process regulated personal data unless justified, regenerate the population, and sample-test that attestations target real exposure.