Security Safeguards and Technical Control Testing
Configured, enabled, and working are three different claims
Privacy auditors do not need to be penetration testers, but they must evaluate whether technical safeguards operate as intended. Core areas include access control and least privilege, authentication strength including multi-factor, encryption in transit and at rest with key management, logging and monitoring, segmentation, secure configuration, and vulnerability management.
Testing technique matters. Inquiry alone is weak evidence. Stronger evidence comes from configuration exports, screenshots taken by the auditor, system-generated reports, log samples, and re-performance or observation. Where the auditor relies on an independent assessment or a service organization report, they must check the report's scope, period, and complementary user entity controls, and confirm those controls are actually implemented.
The recurring trap is the control that is enabled but not enforced: encryption available but not mandatory on a storage bucket, MFA required for administrators but not for vendor accounts, logging on but retention of seven days with no review. Another trap is a sample drawn only from systems the auditor was shown, ignoring shadow IT and unsanctioned SaaS.
Worked example. An entity states access reviews occur quarterly. The auditor obtains two quarters of review evidence and finds 40% of reviewed accounts retained without justification, and no evidence of removal actions. Conclusion: the review is performed but not effective; the finding addresses the disposition step, not the review itself.
Rule of thumb: for each safeguard, ask who configured it, how it is enforced, how exceptions are detected, and what the last exception looked like.