Template
Information security policy template
An information security policy is only auditable when every clause names the control that enforces it. This template pairs 9 policy statements with the Google Workspace setting behind each one, so an assessor can move from the written claim to the admin console evidence in a single step.
Last checked · template reviewed against the current admin console · See what changed
| Policy statements | 9, each mapped to a Workspace control |
|---|---|
| Frameworks supported | ISO 27001, SOC 2, Cyber Essentials preparation |
| Review cycle written in | Annual, plus after any material change |
| Roles named | Policy owner, Workspace admin, approver |
| Format | Plain text, adopt or adapt freely |
| Evidence column | Console location for every clause |
Copy the template
Free to use and adapt, including commercially. Every bracketed placeholder is meant to be replaced before the document is adopted.
Information security policy — plain text
INFORMATION SECURITY POLICY
Organisation: [ORGANISATION]
Policy owner: [NAME, ROLE]
Approved by: [NAME, ROLE] Date: [DATE] Review: [DATE + 12 MONTHS]
1. PURPOSE AND SCOPE
This policy governs how [ORGANISATION] protects information held in
Google Workspace and connected services. It applies to all staff,
contractors and anyone issued with an [ORGANISATION] account.
2. ACCESS CONTROL
Accounts are issued only through the joiner process in [HR SYSTEM].
Super admin is limited to [2] named individual accounts. Shared or
generic admin accounts are prohibited.
Evidence: Admin console > Account > Admin roles.
3. AUTHENTICATION
2-step verification is enforced for all users. Security keys or
passkeys are required for anyone holding an admin role.
Evidence: Admin console > Security > Authentication > 2-step verification.
4. EXTERNAL SHARING
Drive sharing outside [ORGANISATION] is restricted to [allowlisted
domains / warning on external share]. Public "anyone with the link"
sharing is disabled by default.
Evidence: Admin console > Apps > Google Workspace > Drive and Docs >
Sharing settings.
5. THIRD-PARTY APPLICATION ACCESS
Users may not grant third-party applications access to Gmail or Drive
data. New applications are reviewed by [ROLE] before allowlisting.
Evidence: Admin console > Security > Access and data control > API controls.
6. DEVICES
Company data is accessed only from devices enrolled in [endpoint
management]. Screen lock and encryption are required.
Evidence: Admin console > Devices > Mobile and endpoints > Settings.
7. EMAIL AUTHENTICATION
[ORGANISATION] publishes SPF, DKIM and DMARC for every sending domain.
The DMARC policy is [p=reject] and reports are reviewed [monthly].
Evidence: public DNS, plus the DMARC report mailbox.
8. RETENTION AND DELETION
Mail and Drive data are retained for [X] years under Google Vault rules.
Leaver data is retained for [X] months on an Archived User licence
before deletion.
Evidence: Vault > Retention.
9. LOGGING
Login, admin and Drive audit logs are exported to [DESTINATION] and
retained for [X] months beyond the Workspace default.
Evidence: Admin console > Reporting > Audit and investigation.
10. SUPPLIERS
Suppliers processing our data are reviewed annually against [CRITERIA]
and listed in [REGISTER].
11. INCIDENT REPORTING
Suspected incidents are reported immediately to [NAME / ADDRESS] and
handled under the [INCIDENT RESPONSE PLAN].
12. BREACHES OF THIS POLICY
Breaches are handled under the [DISCIPLINARY PROCEDURE].
13. REVIEW
This policy is reviewed annually by [ROLE] and after any material
change to the environment.Write clauses an assessor can verify in a minute
The difference between a policy that passes review and one that generates findings is specificity. A clause that says strong authentication is required invites the question of what strong means and who checks. A clause that says two-step verification is enforced for all users, with the console location written beside it, answers the question before it is asked.
Each numbered section in this template therefore ends with an evidence line naming where the control lives. When an assessor asks how you know the policy is followed, you open that screen. That structure also makes the policy self-maintaining: if the console setting changes, the mismatch is obvious at the next review rather than two years later.
The nine controls this policy commits you to
The template is deliberately short. Nine substantive controls covering access, authentication, external sharing, third-party application grants, devices, mail authentication, retention, logging and suppliers cover the overwhelming majority of what small and mid-sized organisations are actually asked to evidence.
Longer policies are not better. A forty-page document nobody has read produces worse outcomes than four pages everybody has, because the clauses that matter get lost among clauses copied from a template written for a different kind of business entirely.
- Access: super admin limited to a named, counted set of accounts
- Authentication: 2-step verification enforced, keys or passkeys for admins
- Sharing: public link sharing disabled by default
- Applications: no unreviewed OAuth grants against Gmail or Drive
- Mail: SPF, DKIM and DMARC published for every sending domain
- Retention and logging: Vault rules plus exported audit logs
Filling in the bracketed values honestly
Every bracket in the template is a decision, and the temptation is to write the answer you wish were true. Resist it. A policy claiming DMARC is at p=reject when the published record says p=none is worse than no policy, because it converts a technical gap into a documented misstatement that an assessor or an insurer can point at.
Where you are not yet at the target state, write the current state and add a dated remediation note beneath the clause. Assessors accept a known gap with an owner and a date far more readily than they accept a claim that does not survive a DNS lookup.
What we see that others don't say
Assessors reject security policies far more often for being unevidenced than for being incomplete: a clause stating that access is restricted to authorised personnel proves nothing, whereas a clause stating that super admin is limited to two named accounts is checkable in the admin console in under a minute.
What this doesn't cover
- This is a template, not certification. Adopting it does not make an organisation ISO 27001 or SOC 2 compliant.
- It covers the Google Workspace layer. Physical security, HR screening and software development lifecycle controls are not included.
- Retention periods and supplier criteria are jurisdiction and sector specific and must be set by your own advisers.
- Console locations were verified on the date shown and move between Google releases.
Want this done for you?
Three fields. We come back with whether this is a 20-minute fix or a project, and what it costs.
Prefer to talk? Call +44 20 7183 3436 (Mon–Fri 08:00–18:00 GMT), or message WhatsApp +44 7403 423563.
Questions we get asked
- Is this information security policy template free?
- Yes, free to copy, adapt and adopt commercially with no attribution required. It is offered as a starting document, not as certified compliance material.
- Will this policy pass an ISO 27001 audit?
- It supports preparation by giving each clause a verifiable control, but certification depends on your full management system and your assessor's judgement, not on any single document.
- How long should an information security policy be?
- Short enough that staff read it. Nine substantive controls across four pages beats a forty-page document copied from a different industry, because the clauses that matter stay visible.
How this page is verified
Reviewed by Workspace Migration Services security desk, Workspace security and compliance reviewers. Last checked .
- Console locations verified against the Google Admin console on 2026-08-07.
- Clause structure reflects the evidence requests Workspace Migration Services has responded to in client due-diligence questionnaires to 2026-08-07.
Sources you can check
Cite this page
Free to reuse with attribution. Copy whichever form your publication needs.
Plain citation
Workspace Migration Services, "Information security policy template", https://workspacemigration.services/templates/information-security-policy-template (last checked 2026-08-07).HTML with source link
<p>A security policy clause is only auditable when it names the enforcing control, such as limiting Google Workspace super admin to two named accounts rather than stating that access is restricted. Source: <a href="https://workspacemigration.services/templates/information-security-policy-template">Information security policy template</a> — Workspace Migration Services.</p>Embed this table
<table>
<caption>Information security policy template — Workspace Migration Services, 2026-08-07</caption>
<tr><th>Policy statements</th><td>9, each mapped to a Workspace control</td></tr>
<tr><th>Frameworks supported</th><td>ISO 27001, SOC 2, Cyber Essentials preparation</td></tr>
<tr><th>Review cycle written in</th><td>Annual, plus after any material change</td></tr>
<tr><th>Roles named</th><td>Policy owner, Workspace admin, approver</td></tr>
<tr><th>Format</th><td>Plain text, adopt or adapt freely</td></tr>
<tr><th>Evidence column</th><td>Console location for every clause</td></tr>
</table>
<p><a href="https://workspacemigration.services/templates/information-security-policy-template">Information security policy template</a> — data maintained by Workspace Migration Services.</p>Related pages
Need the policy backed by the console settings it claims?
An audit checks each clause against your live tenant and returns the mismatches, so the document you hand an assessor describes the environment you actually run.