AD7.2 The Four Essential Security Policies

Policy design principles

Effective security policies share three characteristics:

Short. A policy that's 30 pages long doesn't get read. Each of the four policies should be 1-3 pages. If you can't fit it in 3 pages, you're including implementation details that belong in a procedure document (like the AD6 response procedures) rather than the policy itself. The policy states WHAT and WHY. The procedure documents state HOW.

Written in plain language. "All users shall authenticate using multi-factor authentication methods approved by the IT department for access to corporate information systems" becomes "Everyone must use MFA to sign in to M365. The IT team will help you set up the Authenticator app." Same requirement, half the words, ten times more likely to be understood.

Enforceable by technical controls. A policy that says "users should not share sensitive data externally" is unenforceable if you don't have DLP. A policy that says "sensitive data (Confidential and Highly Confidential labels) must not be shared externally without encryption" is enforceable because you've deployed the DLP policies and sensitivity labels (AD4) that implement it. Write policies that your controls can enforce — then the policy isn't just guidance, it's backed by technology.

Password and Authentication Policy — complete template

Save this as a Word document, adapt the bracketed sections to your environment, and submit for management approval:

PASSWORD AND AUTHENTICATION POLICY
[Organization Name]
Version 1.0 | Effective: [Date] | Approved by: [Name, Title]
Review date: [12 months from effective date]

1. PURPOSE
This policy establishes the authentication requirements for accessing
[Organization Name]'s Microsoft 365 environment and related systems.

2. SCOPE
All employees, contractors, and third parties who access
[Organization Name]'s M365 environment.

3. MULTI-FACTOR AUTHENTICATION
3.1 MFA is required for all users. No exceptions except the
    documented break-glass accounts.
3.2 Approved MFA methods: Microsoft Authenticator app (preferred),
    FIDO2 security keys, hardware tokens.
3.3 SMS-based MFA is discouraged. Users currently using SMS must
    migrate to the Authenticator app within 90 days.
3.4 Users must not approve MFA prompts they did not initiate. Report
    unexpected MFA prompts to IT immediately.

4. PASSWORD REQUIREMENTS
4.1 Passwords must be at least 14 characters.
4.2 Password expiration is not enforced (per NIST SP 800-63B guidance).
4.3 Previously breached passwords are blocked (Entra ID Password
    Protection).
4.4 Users must not reuse passwords across work and personal accounts.

5. ACCOUNT SECURITY
5.1 Users must not share account credentials with anyone.
5.2 Shared mailboxes use delegated access, not shared passwords.
5.3 Break-glass accounts exist for emergency access. Access is
    documented and reviewed quarterly.
5.4 Accounts inactive for 90+ days are reviewed and disabled if no
    longer needed.

6. CONDITIONAL ACCESS
6.1 Access to M365 is restricted to compliant, managed devices
    (CA003 policy).
6.2 Unmanaged devices may access M365 through app protection
    policies with restricted functionality.
6.3 Administrative access requires additional MFA and is restricted
    to designated admin accounts.

7. ENFORCEMENT
This policy is enforced through technical controls in Microsoft
Entra ID and Intune. Violations detected through monitoring are
investigated by the IT team.

This policy is 1 page. It authorizes every authentication control you deployed in AD1. When a user asks "why do I need MFA?", point them to section 3. When an auditor asks about password policy, point them to section 4. When a contractor asks about access, point them to section 2.

Data Classification Policy — complete template

DATA CLASSIFICATION POLICY
[Organization Name]
Version 1.0 | Effective: [Date] | Approved by: [Name, Title]

1. PURPOSE
This policy establishes the classification framework for
[Organization Name]'s information assets.

2. CLASSIFICATION LEVELS
2.1 PUBLIC — Approved for external distribution. Examples: marketing
    materials, published specifications, job listings.
2.2 INTERNAL (DEFAULT) — For [Organization Name] employees only.
    Examples: meeting notes, project plans, internal procedures.
2.3 CONFIDENTIAL — Sensitive information that would cause harm if
    disclosed. Examples: client contracts, financial reports, vendor
    pricing, employee personal data. Encryption is applied
    automatically.
2.4 HIGHLY CONFIDENTIAL — Most sensitive. Access restricted to
    named individuals. Examples: board papers, salary data, security
    incident reports. Encryption with user-specified access.

3. CLASSIFICATION REQUIREMENTS
3.1 All documents and emails must be classified using sensitivity
    labels in Microsoft 365.
3.2 New documents are automatically classified as INTERNAL.
3.3 Users must reclassify to a higher level when the content warrants
    it (client data → CONFIDENTIAL; board papers → HIGHLY CONFIDENTIAL).
3.4 Downgrading a classification requires a documented justification.

4. HANDLING REQUIREMENTS
4.1 CONFIDENTIAL and HIGHLY CONFIDENTIAL content must not be shared
    externally without encryption.
4.2 External sharing of any classification requires authenticated
    access (anonymous links are disabled).
4.3 Bulk transfers of sensitive data are monitored by DLP policies.
    Users can override DLP blocks with business justification.

5. ENFORCEMENT
This policy is enforced through Microsoft Purview sensitivity labels
and Data Loss Prevention policies. Violations are logged and
reviewed weekly.

This is also 1 page. It authorizes everything you deployed in AD4: the label taxonomy, the encryption, the sharing controls, and the DLP policies. The policy and the technology are aligned — the labels implement the classification levels, the DLP implements the handling requirements, and the monitoring implements the enforcement.

Getting policies approved by management

The policies are written. Now they need management approval. The approval process matters — a policy signed by the IT administrator alone has no organizational authority. A policy approved by the managing director or department head has the weight to support enforcement.

The approval meeting (15 minutes). Don't email the policies and hope for a response. Schedule a 15-minute meeting with your manager. Bring printed copies of all four policies. Walk through each one in 3 minutes: "This is the Password Policy — it documents the MFA requirement we deployed in Module AD1. This is the Data Classification Policy — it documents the four labels we deployed in Module AD4. These policies authorize the controls that are already working. I need your signature to make them organizational policy rather than IT decisions."

What to say if management pushes back: "These policies don't add new requirements — they document what's already deployed and working. The quarterly report demonstrates the results. Without policies, the controls are technically in place but not organizationally authorized — which creates risk during audits, user disputes, and personnel changes."

After approval: Distribute the policies to all employees. For the AUP specifically, require a signed acknowledgment (physical or electronic). Store the signed policies and acknowledgments in the governance document library. Set a calendar reminder for the annual review.

Policy review and update process

Policies are not static. Review and update when:

Annually (mandatory). Read each policy. Verify every statement matches the current technical configuration. Update version numbers. If significant changes are needed, recirculate for management approval.

After a significant control change. If you deploy a new CA policy (e.g., CA004 for named location blocking), update the Password and Authentication Policy to reference it. If you change the label taxonomy, update the Data Classification Policy. The policy must match the technology at all times.

After an incident that reveals a policy gap. If a post-incident review (AD6.10) identifies a policy gap — "the AUP doesn't address [scenario]" — update the policy to close the gap. This is the continuous improvement cycle: incident → review → policy update → control improvement.

After regulatory changes. If UK GDPR requirements change, or if your sector introduces new regulations, review the policies for alignment. The annual review is the natural checkpoint for regulatory changes.

Adapting policies for your jurisdiction

The policy templates in this module use UK GDPR and UK employment law references (ICO Employment Practices Code, Data Protection Act 2018). If your organization is outside the UK, adapt the legal references to your local legislation:

Australia: Replace GDPR references with Privacy Act 1988 and Australian Privacy Principles (APPs). Replace ICO references with the Office of the Australian Information Commissioner (OAIC).

Canada: Replace GDPR with PIPEDA (Personal Information Protection and Electronic Documents Act) or provincial equivalents (e.g., Quebec's Law 25). Replace ICO with the Office of the Privacy Commissioner of Canada.

US: Privacy requirements vary by state and industry. Reference applicable frameworks: CCPA/CPRA (California), HIPAA (healthcare), GLBA (financial), or industry-specific standards. There's no single US equivalent to GDPR — your legal counsel should review which regulations apply.

EU: GDPR applies directly — the UK GDPR references in these templates translate to EU GDPR with minimal changes (replace "ICO" with your national data protection authority).

The security controls are identical regardless of jurisdiction — MFA works the same everywhere. Only the legal references in the policies need localisation. Have your local legal counsel review the adapted policies before management approval.