AD7.10 Program Handover and Sustainability

The handover document

When you hand over the security program (role change, extended leave, or cross-training a colleague), provide this one-page handover:

SECURITY PROGRAMME HANDOVER
Prepared for: [Colleague name]  |  Date: [Date]

READ FIRST:
Program Summary: [location] (30 min read — covers everything)

WEEKLY (every Monday):
1. Open: [bookmarked incident queue URL]
2. Run: C:\SecurityScripts\Monday-Security-Review.ps1
3. Follow: Monday Review Checklist (printed at your desk)
4. Log: Results in [weekly security log location]
5. If incident found: Follow IR procedures in C:\SecurityScripts\

MONTHLY (first business day):
1. Run: C:\SecurityScripts\Get-QuarterlyReport.ps1
2. Record metrics in [spreadsheet location]

QUARTERLY (first business day):
1. Produce quarterly report from template at [location]
2. Send to [manager name/email]
3. Review exception registers (CA, compliance, DLP)
4. Run SharePoint external sharing audit

IF AN INCIDENT OCCURS:
1. Run C:\SecurityScripts\Preserve-Evidence.ps1 -User [UPN]
2. Follow procedure in C:\SecurityScripts\ (compromised account,
   phishing, or BEC)
3. Escalate if needed: [SOC email], [SOC phone], [manager email]
4. Document using template at C:\SecurityScripts\IncidentReportTemplate.md

KNOWN PATTERNS:
- [CEO] travels frequently → impossible travel alerts are usually FP
- [MarketingApp] service principal signs in daily at 06:00 → expected
- CA003 blocks from [VPN IP] are legitimate BYOD users

QUESTIONS? Contact [your name] at [personal phone/email]

This one-page handover enables a competent IT administrator to operate the security program immediately. The program summary provides depth; the handover provides the daily operational instructions.

Annual program review

Schedule an annual review (same week every year) to ensure the program stays current:

Policy review (1 hour). Re-read each policy. Are the controls still accurate? Have requirements changed? Update version numbers. Recirculate for management re-approval if significant changes.

Program summary update (30 minutes). Verify every control listed in the summary matches the current configuration. Check for undocumented changes. Update the change log.

Procedure testing (30 minutes). Execute the compromised account procedure against a test account. Verify PowerShell commands work with current module versions. Update any commands that have changed.

Gap assessment (30 minutes). Review Section 9 (Known Gaps) of the program summary. Have any gaps been closed? Have new gaps emerged? Update the E5 business case if applicable.

Escalation contact verification (15 minutes). Confirm all escalation contacts are still correct (managed SOC, legal, manager, external IR). Update phone numbers and email addresses.

Total annual review: approximately 3 hours. The investment ensures the program stays current, the procedures work, and the documentation is accurate. An annual review that discovers a broken PowerShell command is 3 hours well spent compared to discovering it during a real incident.

Cross-training for program resilience

Single-person dependency is the program's biggest risk. Even with perfect documentation, a colleague who has never used the tools will be slower and less confident than one who has practised. Build resilience through cross-training:

Monthly shadow session (15 minutes). Invite a colleague to observe your Monday security review once per month. They watch you navigate the portals, interpret the data, and make classification decisions. After 3-4 shadow sessions, they can execute the review independently.

Quarterly procedure walkthrough (30 minutes). Walk a colleague through one incident response procedure on a test account. They execute the commands while you observe. This builds muscle memory — they've actually run Revoke-MgUserSignInSession, not just read about it.

Annual handover drill (1 hour). Give your colleague the handover document. Leave the room. They execute the Monday review independently using only the documentation. Debrief: what was clear, what was confusing, what needs updating in the documentation? This drill validates both the documentation quality and the colleague's readiness.

The cross-training investment: approximately 5 hours per year (12 shadow sessions at 15 min, 4 procedure walkthroughs at 30 min, 1 handover drill at 1 hour). The return: a second person who can maintain the security program during your absence. This is cheaper and more effective than hiring a dedicated security analyst for most SMBs.

Program maturity progression

Your security program evolves through three maturity stages:

Stage 1: Deployed (where you are now). Controls configured, monitoring active, procedures written, governance documented. The program operates on E3 with 30-45 minutes per week. This is a strong security posture that exceeds what most SMBs achieve.

Stage 2: Optimised (6-12 months). Post-incident improvements implemented, DLP tuned for low false-positive rate, Secure Score stabilised at 65%+, quarterly reports showing positive trends, baseline security certification achieved (if applicable to your region), cross-trained colleague operational. The program runs smoothly with established baselines for what "normal" looks like.

Stage 3: Advanced (12-24 months). E5 add-ons deployed (Entra ID P2, Defender for Endpoint), advanced detections operational, phishing simulation program running, integration with Sentinel for custom analytics, program feeding into broader risk management. At this stage, the security program is a strategic business capability, not just an IT function.

Each stage builds on the previous one. You don't skip stages — the E5 investment at Stage 3 only makes sense because the E3 foundation at Stage 1 is solid. The post-incident improvements at Stage 2 only work because the monitoring at Stage 1 catches the incidents. The progression is organic — driven by your operational experience, incident data, and business needs.

Measuring program sustainability

Track these indicators quarterly to verify the program is sustainable:

Monday review completion rate. Target: 13/13 weeks per quarter. If reviews are being skipped (holiday weeks, busy weeks), the detection cadence is degrading. If the rate drops below 10/13, investigate why — is the 15-minute commitment unsustainable, or are other priorities crowding it out?

Incident response time. Target: under 60 minutes from detection to containment for compromised accounts. If response times are increasing, the procedures may need refreshing or the responder may need re-training.

Documentation currency. Check the "last updated" date on the program summary and each policy. If any document is more than 12 months old without review, it's at risk of being out of date. The annual review prevents this — but only if it actually happens.

Cross-training status. Is there a second person who can execute the Monday review and basic incident response? If the answer is "no" for more than 6 months, schedule the cross-training. Single-person dependency is an accepted risk in Stage 1 — it should be resolved by Stage 2.

The single-point-of-failure assessment

Conduct this assessment honestly. For each program component, answer: "If I'm unavailable for 3 weeks, will this still happen?"

Any "HIGH" risk component needs a mitigation before your next holiday. The Monday review and incident response are the two critical components — everything else can wait 3 weeks without significant risk.

The mitigation is always the same: a second person who can execute the component using the documentation you've built. The cross-training investment (5 hours per year from AD7.10) is the cheapest insurance against single-point-of-failure risk.

Program sustainability checklist — annual verification

Run this checklist annually alongside the policy and program summary review:

PROGRAMME SUSTAINABILITY CHECKLIST — ANNUAL

[ ] All policies reviewed and current (version dates < 12 months)
[ ] Program summary reviewed and matches current configuration
[ ] All PowerShell scripts tested and working
[ ] All escalation contacts verified (names, numbers, emails)
[ ] Handover document updated with current locations and patterns
[ ] Cross-trained colleague has completed at least 4 shadow sessions
[ ] Quarterly reports produced for all 4 quarters
[ ] Incident procedures tested on test account
[ ] Evidence folder structure maintained
[ ] Governance document library organized and accessible
[ ] Calendar appointments active for all recurring activities
[ ] No single-point-of-failure risks rated HIGH without mitigation

Reviewed by: _____________ Date: ___________
Next review: _____________

This checklist is the meta-governance — it verifies that the governance itself is maintained. Store the completed checklist in the governance document library. Each completed annual checklist demonstrates program maturity to auditors: "We review the program annually against a sustainability checklist. Here are the last 3 years of completed checklists."

Program health indicators — what to watch for

Beyond the formal sustainability metrics, watch for these informal indicators that the program is healthy or degrading:

Healthy indicators: Monday reviews happen consistently (13/13 weeks). Incidents are documented within 24 hours of containment. The quarterly report is produced on time. Your colleague can describe the program in one paragraph. Management references the quarterly report in their own communications.

Degradation indicators: Monday reviews are skipped "because nothing ever happens." Incidents are handled but not documented. The quarterly report is produced late or skipped. The program summary hasn't been updated in 6+ months. New controls are deployed without updating the documentation. A new team member asks about the security program and nobody can point them to a document.

If you notice degradation indicators, the fix is always the same: go back to the documentation (program summary, checklists, procedures) and verify they're current. The documentation is both the product AND the maintenance mechanism of the governance layer — keeping the documentation current keeps the program healthy. Letting the documentation lapse is how programs degrade from "operational" to "it's configured somewhere but nobody really knows the details."