In this module

AD7.6 The Security Program Summary Document

5-6 hours · Module 7 · Free

Operational Objective

The quarterly report shows outcomes. The policies authorize controls. But neither document describes the complete security architecture — every control deployed, every configuration choice, every monitoring process, and every response procedure. The security program summary is the "system of record" for your security program: the document a new IT administrator reads on their first day, that an auditor reviews during assessment, and that you reference when troubleshooting why a control exists. This subsection provides the complete program summary template — a living document that captures everything you've built across Modules AD1-AD7.

Deliverable: A security program summary document covering all deployed controls, configurations, monitoring processes, and response procedures — the definitive reference for your M365 security architecture.

Estimated completion: 30 minutes

Figure AD7.6 — The program summary covers both architecture (what's configured) and operations (how it's maintained). Together they form the complete reference for anyone who needs to understand, maintain, or audit the security program.

Program summary template

SECURITY PROGRAMME SUMMARY
[Organization Name]
Version 1.0 | Last updated: [Date] | Author: [Name]
Next review: [6 months from last update]

1. PROGRAMME OVERVIEW
Environment: Microsoft 365 E3, [X] users, [X] devices
Deployment period: [start date] to [end date]
Maintenance commitment: 30-45 minutes/week
Total controls deployed: [X] CA policies, [X] compliance policies,
  [X] DLP policies, [X] sensitivity labels, [X] email protection
  policies
Licensing: All controls operate within M365 E3. No additional cost.

2. IDENTITY SECURITY (Module AD1)
2.1 MFA: Required for all users. Enforced by CA001 (all users)
    and CA002 (admin accounts). Break-glass accounts: 2 (BG-Admin-01,
    BG-Admin-02). Approved methods: Authenticator app, FIDO2.
2.2 Conditional Access:
    - CA001: Require MFA for all users (all cloud apps)
    - CA002: Require MFA for admin roles (phishing-resistant preferred)
    - CA003: Require compliant device (all cloud apps, excludes BYOD
      with app protection)
    [Add any additional CA policies]
2.3 Exceptions: [List any documented exceptions with justification]
2.4 Configuration location: entra.microsoft.com → Protection →
    Conditional Access

3. EMAIL PROTECTION (Module AD2)
3.1 Safe Links: Enabled for all users. URL scanning on click.
    Wrap URLs in Teams messages. Wait for scanning to complete.
3.2 Safe Attachments: Enabled. Dynamic Delivery mode. Block
    malicious attachments.
3.3 Anti-phishing: Impersonation protection for [X] VIP users.
    Mailbox intelligence enabled.
3.4 DMARC: [current status — p=none/quarantine/reject]
    SPF: [record details]. DKIM: [enabled/disabled].
3.5 Configuration location: security.microsoft.com → Policies
    & rules → Threat policies

4. DEVICE SECURITY (Module AD3)
4.1 Compliance policies:
    - Windows: OS version [min], BitLocker required, firewall on,
      Defender AV active, real-time protection on
    - macOS: [if applicable]
    - iOS/Android: [if applicable]
4.2 CA integration: CA003 requires compliant device. Non-compliant
    devices redirected to app protection or blocked.
4.3 BYOD: App protection policies for Outlook and Teams. No
    full device management required for personal devices.
4.4 Configuration location: intune.microsoft.com → Devices →
    Compliance

5. DATA PROTECTION (Module AD4)
5.1 Sensitivity labels: 4-tier taxonomy (Public, Internal,
    Confidential, Highly Confidential). Default: Internal.
    Mandatory labeling enabled.
5.2 Encryption: Confidential = internal users only.
    Highly Confidential = user-specified access.
5.3 DLP policies:
    - Personal Data Protection: UK NINO, credit card, passport
    - Financial Data Protection: bank account, SWIFT, bulk credit card
5.4 SharePoint sharing: Anonymous links disabled. Authenticated
    sharing only. HR/Finance/Legal: no external sharing.
5.5 Configuration location: purview.microsoft.com → Information
    Protection + Data Loss Prevention

6. SECURITY MONITORING (Module AD5)
6.1 Monday security review: 5 checks, 15 minutes, every Monday
    at 09:00. Checklist at [location].
6.2 Alert notifications: High severity = immediate email.
    Medium = daily digest. Low/Info = Monday review.
6.3 Secure Score: checked weekly. Current: [X]%.
6.4 Scripts: C:\SecurityScripts\Monday-Security-Review.ps1
6.5 Weekly security log: [location of CSV/spreadsheet]

7. INCIDENT RESPONSE (Module AD6)
7.1 Procedures:
    - Compromised Account: AD6.2 (5-step, 15 minutes)
    - Phishing Click: AD6.3 (scope + contain + purge)
    - BEC: AD6.4 (10-step including finance notification)
7.2 Evidence preservation: Preserve-Evidence.ps1 (run before
    containment)
7.3 Escalation: [managed SOC contact] for after-hours.
    [Manager name] for management notification. [Legal contact]
    for GDPR assessment.
7.4 Incident Response Plan: [document location]
7.5 Incident report template: C:\SecurityScripts\IncidentReportTemplate.md

8. GOVERNANCE (Module AD7)
8.1 Policies: Acceptable Use (approved [date]), Password &
    Authentication (approved [date]), Data Classification (approved
    [date]), Incident Response Plan (approved [date]).
8.2 Quarterly report: produced first week of each quarter.
    Reports archived at [location].
8.3 Annual review: policies and program summary reviewed annually.
    Next review: [date].

9. KNOWN GAPS AND RISK ACCEPTANCE
9.1 No Defender for Endpoint (requires E5) — compensated by Intune
    compliance and Defender Antivirus configuration profiles.
9.2 No auto-labeling (requires E5) — compensated by default +
    mandatory labeling.
9.3 No Endpoint DLP (requires E5) — compensated by email/SharePoint
    DLP only.
9.4 [Any other documented gaps with compensating controls]

10. CHANGE LOG
| Date | Change | Author |
|------|--------|--------|
| [date] | Initial program deployment | [name] |
| [date] | Added DLP policies (AD4) | [name] |
| [date] | Quarterly review — no changes | [name] |

This document is 3-4 pages. It's the single reference for the entire security program. A new administrator reads this and understands: what's configured (sections 2-5), how to operate it (sections 6-7), what governs it (section 8), and where the gaps are (section 9). The change log (section 10) tracks every modification.

Update this document whenever you make a significant change: new CA policy, new DLP rule, new compliance requirement. The document stays current because it's the operational reference — you check it when troubleshooting, when answering audit questions, and when onboarding a new team member.

Maintaining the program summary — practical workflow

The program summary is a living document, not a one-time deliverable. Keep it current with this workflow:

Immediate updates (within 24 hours of a change). When you deploy a new CA policy, add a DLP rule, change a compliance threshold, or update an escalation contact — update the program summary the same day. Open the document, update the relevant section, add an entry to the change log (Section 10), and save. This takes 5 minutes per change. If you defer updates, they accumulate and the document becomes stale.

Monthly verification (5 minutes). During your monthly metric collection (first business day), scan the program summary quickly: does Section 2 (Identity) still match the CA policies in the portal? Does Section 5 (Data) still match the DLP policies? Any mismatches indicate undocumented changes — either you forgot to update the document, or another admin made a change you weren't aware of. Either way, update the document.

Quarterly alignment (15 minutes). During the quarterly report production, verify that the program summary and the quarterly report tell consistent stories. If the quarterly report shows "3 CA policies active" but the program summary lists 4, there's a discrepancy. Resolve it and update both documents.

Version numbering. Use simple version numbering: 1.0 (initial deployment), 1.1 (first update), 1.2 (second update), 2.0 (annual review version). Major version increments (1.0 → 2.0) happen at the annual review. Minor increments happen for each change. The version number in the document header, combined with the change log, creates a complete audit trail of program evolution.

Storing the program summary

Store the program summary where it's accessible but protected:

Primary location: A SharePoint document library with restricted access (IT staff only). Not the user-accessible intranet — the program summary contains configuration details that users don't need and shouldn't have (CA policy conditions, DLP SIT thresholds, escalation contacts).

Backup copy: Export as PDF and save to your evidence folder (C:\SecurityScripts\ or equivalent). The PDF is a point-in-time snapshot — useful if the SharePoint version is accidentally modified.

Printed copy: Print the current version and keep it at your desk. During an incident, a printed program summary is faster to reference than navigating to SharePoint. Update the printed copy when you update the digital version.

The program summary is the most valuable governance document in your program. It's the document that enables continuity (handover to a new admin), supports audit (comprehensive reference for assessors), and aids troubleshooting (quick reference for "why is this configured this way?"). Invest 5 minutes per change to keep it current — the return is disproportionate to the effort.

Using the program summary for daily troubleshooting

Beyond governance and audit purposes, the program summary is your daily troubleshooting reference. Common scenarios:

"Why can't I access M365 from my personal laptop?" → Program summary Section 4.2: "Access to M365 is restricted to compliant, managed devices (CA003). Personal devices access via app protection policies with restricted functionality." You have the answer in 10 seconds instead of navigating to the Entra portal to check CA policy conditions.

"What DLP policies are blocking my email?" → Program summary Section 5.3: "Personal Data Protection policy detects UK NINO, credit card, passport. Financial Data Protection policy detects bank account, SWIFT, bulk credit card. Both block external sharing with user override." You can explain the block to the user without opening Purview.

"What's our DMARC status?" → Program summary Section 3.4: "DMARC: p=quarantine, deployed [date]. SPF: record details. DKIM: enabled." You have the answer for the client questionnaire without checking DNS records.

"What should I do if a user's account is compromised?" → Program summary Section 7.1: "Compromised Account: AD6.2 (5-step, 15 minutes)." Points you directly to the procedure.

The program summary saves 5-10 minutes per question by providing immediate answers to common queries. Over a year, that's 2-4 hours saved — from a document that took 90 minutes to create. Each question you answer from the document instead of from the portal validates the investment in documentation.

The program summary as single source of truth

Establish one rule across your team: "If it's not in the program summary, it's not part of the program." This rule drives documentation discipline — every new control, every configuration change, every exception must be recorded in the program summary before it's considered "deployed."

The rule works in both directions. When someone asks "do we have X configured?" the answer comes from the program summary, not from memory or portal exploration. If the program summary says "CA003: Require compliant device for all cloud apps" and someone discovers the policy is actually disabled in the portal, that's a discrepancy to investigate — either the summary is wrong (update it) or the configuration drifted (fix it).

This single-source-of-truth discipline eliminates the scenario where different team members have different understandings of the security architecture. The program summary is the canonical reference — disagreements are resolved by checking the document and verifying against the portal. Over time, this discipline becomes automatic: make a change in the portal, update the program summary, log it in the change log. Three actions, always together.

Compliance Myth: "A program summary is just documentation for documentation's sake"

The program summary has three practical uses beyond compliance. First, it's your troubleshooting reference: "Why is this user blocked from M365?" → check Section 4.2 (CA003 compliance requirement). "What DLP policies are active?" → check Section 5.3. Second, it's your audit response: "Describe your information security program" → hand them the program summary. Third, it's your continuity insurance: if you're unavailable for 2 weeks, your colleague reads this document and can maintain the program. Each use case is practical and time-saving — the 2 hours you spend writing this document saves 20+ hours of explanation, troubleshooting, and audit preparation over the next year.

Decision point

You've completed the program summary. How often should you update it?

Option A: Annually — during the policy review cycle.

Option B: After every significant change (new CA policy, new DLP rule, new compliance requirement) AND during the annual review. The change log (Section 10) captures each update. Major changes (new CA policy) update immediately — the document must be current to be useful. Minor changes (threshold adjustment) can batch during quarterly review. The annual review confirms everything is still accurate even if no changes were logged.

The correct answer is Option B. A document that's updated once a year is out of date for 11 months. Update after significant changes and verify annually. The change log provides the audit trail of what changed and when.

Try it: Write your security program summary

Copy the template into a Word document. Fill in each section from your deployed configurations:

1. Section 2 (Identity): Open entra.microsoft.com → Conditional Access. List your CA policies with conditions. 2. Section 3 (Email): Open security.microsoft.com → Threat policies. Record Safe Links, Safe Attachments, anti-phishing settings. 3. Section 4 (Devices): Open intune.microsoft.com → Compliance. Record your compliance policies. 4. Section 5 (Data): Open purview.microsoft.com. Record labels, DLP policies, sharing settings. 5. Sections 6-7: Reference your monitoring checklist and IR procedures. 6. Section 9: Document any known gaps (E5 features not available).

Time the exercise. Your target: complete in 90 minutes for the first version. Subsequent updates take 10-15 minutes per change.

A new IT administrator joins your team. What's the most efficient way to onboard them on the security program?

Walk them through every portal and explain each configuration — Time-consuming and information overload. They'll forget 80% by tomorrow.

Give them admin access and let them explore — They'll discover controls but won't understand the rationale, exceptions, or operational procedures.

Give them the program summary to read (30 minutes), then walk them through the Monday security review together (15 minutes), then have them shadow you during the next incident response. The document provides the architecture, the review provides the operations, and the incident provides the response — covering all three dimensions of the program — Correct. The program summary + Monday review + incident shadowing onboards a new administrator in under 2 hours. Without the document, the same onboarding takes 2-3 days of ad-hoc explanations.

Send them to this training course — The course teaches HOW to build a program. The program summary shows WHAT was built in your specific environment. Both are valuable but serve different purposes.

Operational Artifact — Security Program Summary

Complete program summary template: 10 sections covering program overview, identity, email, devices, data, monitoring, incident response, governance, known gaps, and change log. Total: 3-4 pages. Update after significant changes + annual review. The document is the single reference for the entire security program — used for troubleshooting, audit response, and personnel onboarding. Store alongside the quarterly reports and security policies in a restricted-access document library.

💬

How was this module?

Your feedback helps us improve the course. One click is enough — comments are optional.

Thank you — your feedback has been received.

You're reading the free modules of M365 Security: From Admin to Defender

The full course continues with advanced topics, production detection rules, worked investigation scenarios, and deployable artifacts.

View Pricing See Full Syllabus

← Previous Next →