Into the current¶

Now you enter the water. This phase puts everything you have prepared into action and demonstrates that it works under real conditions, not just in documentation.

Phase your launch intelligently¶

Months 1-3: establish core capabilities: Activate critical technical controls to protect your most critical assets. Operationalise incident detection so you can identify when something goes wrong. Begin security monitoring with logging and alerting. Start the awareness training programme across all staff. Establish regular governance meetings so leadership remains informed and engaged.

Months 4-6: complete full implementation: Deploy remaining technical measures mapped during planning. Activate business continuity capabilities with tested procedures. Roll out supply chain security processes to assess and monitor vendors. Implement vulnerability management with scanning and remediation tracking. Establish formal incident reporting procedures with templates and contact lists ready for use.

Months 7-9: focus on testing and validation: Conduct tabletop exercises walking through incident scenarios without putting actual systems at risk. Test incident response procedures under simulated conditions. Validate backup and recovery by actually restoring from backups. Run security awareness assessments to verify training effectiveness. Review and refine processes based on lessons learned. 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-12: optimise and prepare: Address findings from testing, as every exercise reveals gaps. Refine procedures based on operational experience and feedback from users. Prepare compliance evidence organised for potential supervisory review. Conduct an internal audit of your implementation. Ensure readiness for supervisory authority interactions by having clear answers and organised documentation.

Make security business-as-usual¶

Integrate security into existing workflows rather than treating it as a separate activity. People resist bolt-on processes but accept those that are integrated. Automate tasks where possible, such as monitoring, alerting, patching, and reporting, so focus remains on decision-making rather than repetitive work. Establish regular review cycles, monthly or quarterly depending on the process under review. Create metrics and dashboards for board reporting that show trends rather than snapshots. Incorporate security into projects and change processes from the start rather than adding it at the end.

Common challenges appear in every organisation. Resistance arises because people are comfortable with existing ways of working. Alert fatigue may result from monitoring tools producing too many false positives. Competing priorities and resource constraints occur when security needs conflict with delivery pressure. Integration issues can arise between tools that do not communicate. Process bottlenecks occur where necessary approvals slow progress.

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.

Address these challenges through clear communication of regulatory obligations. Help staff understand the reasoning behind changes. Provide practical training and support rather than relying solely on documentation. Roll out changes gradually with feedback loops to allow adjustments based on real experience. Ensure executive sponsorship and accountability to make it clear that security is not optional. Conduct regular process reviews and improvements, recognising that 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.