Implementation of Security and Privacy Controls
Implementation is evidence, not intention
Implementation turns the approved control set into operating reality and records it in the security plan. Each control needs an allocation - system-specific, common/inherited, or hybrid - plus the mechanism used, the responsible role, and where the evidence lives. Implementation should run through the system development life cycle, configuration management, and change control, so a new component is born compliant rather than retrofitted. Privacy controls get the same treatment: notice, consent, minimization, retention and disposal, and complaint handling all need owners and mechanisms.
Common control providers implement once and document what they provide so consuming systems can inherit it. The system owner is accountable for implementation across the boundary; the ISSO usually coordinates, tracks, and maintains documentation.
Traps
The dominant trap is treating a written procedure as an implemented control. A policy saying "audit logs are reviewed weekly" is not evidence that anyone reviews them. Another trap is assuming inherited controls are automatically satisfied - they must be verified and referenced. A third is forgetting that implementation changes require a security impact analysis; teams often patch, migrate, or add an interconnection without revisiting the plan.
Rule of thumb
For every control, be able to state three things in one sentence: the mechanism, the owner, and the evidence. "We do that" is not an answer; "weekly review by the SOC lead, tickets retained in the SIEM" is.