Into the current

Currents

Implementation: putting the preparation into the water and demonstrating that it works under real conditions, not just in documentation.

Phasing the launch

Months 1 to 3 establish core capabilities: critical technical controls protecting the most critical assets, operational incident detection, security monitoring with logging and alerting, the start of awareness training across all staff, and regular governance meetings that keep leadership informed and engaged.

Months 4 to 6 complete the implementation: remaining technical measures mapped during planning, business continuity capabilities with tested procedures, supply chain security processes for assessing and monitoring vendors, vulnerability management with scanning and remediation tracking, and formal incident reporting procedures with templates and contact lists ready for use.

Months 7 to 9 focus on testing and validation: tabletop exercises walking through incident scenarios, incident response procedures under simulated conditions, backup and recovery validated by actually restoring from backups, and awareness assessments verifying training effectiveness.

The evidence produced in this phase is qualitative as well as quantitative. A tabletop that surfaces a gap in the incident reporting chain is more valuable compliance evidence than a completed exercise checklist. A phishing simulation whose click rate has not moved after three campaigns is evidence that the current awareness model needs revision, not that more of the same training is needed. Treat exercise outcomes as model tests: the question is not whether the exercise happened but whether the control produced its intended effect.

Months 10 to 12 optimise and prepare: findings from testing addressed, procedures refined from operational experience, compliance evidence organised for potential supervisory review, an internal audit of the implementation, and readiness for supervisory authority interactions with clear answers and organised documentation.

Making security business-as-usual

Security integrated into existing workflows outlives security bolted on beside them; people resist bolt-on processes and accept integrated ones. Automation of monitoring, alerting, patching, and reporting keeps the focus on decision-making rather than repetitive work. Regular review cycles, metrics and dashboards that show the board trends rather than snapshots, and security present in projects and change processes from the start all push in the same direction.

Common challenges appear in nearly every organisation: resistance rooted in comfort with existing ways of working, alert fatigue from untuned monitoring, competing priorities when security needs collide with delivery pressure, tools that do not talk to each other, and approval bottlenecks.

These challenges are predictable structural features of any significant change to security controls, not signs of failure. Every introduction of new measures goes through a disruption phase before settling into a new stable state: more helpdesk tickets, more workarounds, worse performance metrics before improvements appear. When MFA is introduced, the first weeks generate more friction than the final state will. When a new monitoring tool is deployed, false positive rates are higher before tuning reduces them.

Workarounds that emerge during this phase are information, not non-compliance. They reveal the points where the control’s model does not yet fit the operational environment. Rolling changes out in one team before the full organisation is the mechanism that converts friction into adjustment before it scales.

What helps: clear communication of the regulatory obligations and the reasoning behind changes, practical training and support rather than documentation alone, gradual rollout with feedback loops, executive sponsorship that makes clear security is not optional, and regular process reviews that accept no process is perfect on first implementation.

Output

An operational security programme running daily, tested procedures that staff actually follow, performance metrics showing what works and what does not, and documented lessons learned for continuous improvement.

Last updated: 4 July 2026