# SaaS Productivity Suite Security Baseline: [Organization name]

> Sets the minimum security configuration for the organization's cloud
> productivity suite (e-mail, calendar, chat, file storage and
> collaboration), written for the two common suites, Microsoft 365 and
> Google Workspace, in vendor-neutral terms. Covers identity and MFA,
> conditional access, admin roles, external sharing, e-mail
> authentication (SPF, DKIM, DMARC), audit logging, retention, data loss
> prevention and third-party app consent. Supports ISO/IEC 27001:2022 +
> Amd 1:2024 Annex A controls A.5.15 to A.5.18, A.5.23, A.8.5, A.8.9,
> A.8.12, A.8.15 and A.8.16, with ISO/IEC 27002:2022 guidance.
> Replace every `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Use it when you set up a new tenant, before a certification audit, or
  when reviewing the suite after an account takeover or data leak.
- Fill first: section 3 (tenant facts and admin roles) and section 4
  (identity and MFA). Most suite incidents start with a compromised
  account or an over-privileged admin.
- Settings are described as concepts. Vendors rename admin console menus
  and licence tiers often: check the current admin documentation for the
  exact setting name and the licence it needs, and record the path you
  used in the "Implementation note" column.
- Main pitfall: configuring once and never checking again. New features
  arrive switched on. Review the tenant against this baseline each
  quarter (section 13).
- The CIS Microsoft 365 Foundations Benchmark and the CIS Google
  Workspace Foundations Benchmark are useful detailed checklists. Cite
  them by name and version only.
- Related templates: `isms/secure-configuration-baseline`,
  `isms/access-control-policy`, `isms/endpoint-device-byod-policy`,
  `isms/data-masking-dlp-standard`, `isms/backup-policy`,
  `isms/cloud-services-security-policy`, `security/privileged-access-standard`,
  `security/security-logging-standard`, `data/data-retention-deletion-standard`.
-->

## Document control

<!-- Guidance: This baseline is a child of the secure configuration baseline (CFG-BL-008 there). Record which suite and licence tier it was written for, because available controls differ by tier. -->

| Field | Value |
|---|---|
| Document ID | DOC-ISMS-075 |
| Version | [1.0] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@head-of-it] |
| Approvers/reviewers | [@ciso], [@isms-manager], [@dpo or privacy lead] |
| Last updated | YYYY-MM-DD |
| Effective from | YYYY-MM-DD |
| Classification | [Internal] |
| Standard and edition | ISO/IEC 27001:2022 + Amd 1:2024 (A.5.15 to A.5.18, A.5.23, A.8.5, A.8.9, A.8.12, A.8.15, A.8.16, cited only); ISO/IEC 27002:2022 |
| Next scheduled review | YYYY-MM-DD (quarterly tenant check, annual document review) |
| Suite and licence tier | [Microsoft 365 / Google Workspace], [licence plan names] |
| Tenant or domain | [primary domain], [tenant ID or customer ID] |
| Parent standard | Secure configuration baseline DOC-ISMS-060 (CFG-BL-008) |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Baseline owner | [@head-of-it] | [Prepared] | YYYY-MM-DD |
| ISMS manager | [@isms-manager] | [Reviewed] | YYYY-MM-DD |
| CISO | [@ciso] | [Approved] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 1.0 | YYYY-MM-DD | [@owner] | First issue |
| [x.y] | YYYY-MM-DD | [@author] | [Change summary] |

## Contents

- [1. Purpose and scope](#1-purpose-and-scope)
- [2. Shared responsibility](#2-shared-responsibility)
- [3. Tenant and administration](#3-tenant-and-administration)
- [4. Identity and authentication](#4-identity-and-authentication)
- [5. Conditional access](#5-conditional-access)
- [6. External sharing and collaboration](#6-external-sharing-and-collaboration)
- [7. E-mail security and authentication](#7-e-mail-security-and-authentication)
- [8. Audit logging and alerting](#8-audit-logging-and-alerting)
- [9. Retention, legal hold and backup](#9-retention-legal-hold-and-backup)
- [10. Data loss prevention and labels](#10-data-loss-prevention-and-labels)
- [11. Third-party apps and consent](#11-third-party-apps-and-consent)
- [12. Size tiers](#12-size-tiers)
- [13. Review, deviations and records](#13-review-deviations-and-records)
- [14. References](#14-references)
- [Standard and licence note](#standard-and-licence-note)

## 1. Purpose and scope

<!-- Guidance: The suite usually holds most of the organization's information. Say which services are in scope and which are switched off, because an unused service left on is still an attack path. -->

This baseline protects information in the productivity suite against
account takeover, over-sharing, e-mail spoofing, unauthorised apps and
loss, and makes activity traceable.

| Item | Value |
|---|---|
| Services in scope | [E-mail, calendar, chat and meetings, file storage, collaboration sites, forms, admin console] |
| Services disabled | [Consumer add-ons, unused legacy services, public publishing of sites] |
| Users in scope | All accounts in the tenant: staff, contractors, shared mailboxes, service accounts, guests |
| Out of scope | Line-of-business SaaS (cloud services security policy DOC-ISMS-044) |
| Risk references | [RISK-003 *(Example)*: account takeover by phishing], [RISK-014 *(Example)*: customer files shared publicly] |

## 2. Shared responsibility

<!-- Guidance: A.5.23 expects you to know what the provider does and what you must configure. The provider runs the platform; tenant configuration, identities and data are yours. -->

| Area | Suite provider | [Organization name] |
|---|---|---|
| Platform availability, physical and infrastructure security | Yes | Monitors provider status and certifications |
| Encryption at rest and in transit (platform default) | Yes | Decides on customer-managed keys or client-side encryption where offered and needed |
| Identity configuration, MFA, admin roles | Provides features | Configures and reviews |
| Sharing settings, DLP, retention | Provides features | Configures and reviews |
| Data recovery after user deletion beyond native retention | Limited native retention | Decides on third-party backup (section 9) |
| Audit log retention | Default retention per licence tier | Exports logs where longer retention is needed |

Record the provider's certifications and assurance reports reviewed
(for example ISO/IEC 27001 certificate, SOC 2 Type 2 report) in the
supplier register (DOC-ISMS-066).

## 3. Tenant and administration

<!-- Guidance: Admin accounts are the crown jewels. Count global or super administrators: the usual target is at least two (to avoid lock-out) and no more than a handful. -->

| Setting ID | Requirement | Microsoft 365 concept | Google Workspace concept | Implementation note |
|---|---|---|---|---|
| SAAS-SET-001 *(Example)* | Between 2 and [4] highest-privilege administrators | Global Administrator role | Super Admin role | [Console path checked YYYY-MM-DD] |
| SAAS-SET-002 *(Example)* | Admin accounts are separate, cloud-only accounts without mailbox use for daily work | Dedicated admin accounts | Dedicated admin accounts | |
| SAAS-SET-003 *(Example)* | Least-privilege delegated roles for daily administration (user, helpdesk, billing, security reader) | Built-in role-based admin roles | Pre-built and custom admin roles | |
| SAAS-SET-004 *(Example)* | Just-in-time elevation for highest-privilege roles where the licence allows | Privileged identity management | Time-bound role assignment where available | |
| SAAS-SET-005 *(Example)* | Two break-glass accounts with long random passwords and phishing-resistant MFA, stored per `security/privileged-access-standard`, alerting on any sign-in | Emergency access accounts | Emergency super admin accounts | |
| SAAS-SET-006 *(Example)* | Admin role membership reviewed [quarterly] | Access reviews or manual review | Manual review | Record in `ops/access-review` |

## 4. Identity and authentication

<!-- Guidance: MFA for everyone is the single most effective setting. Then remove the paths that bypass MFA: legacy protocols, app passwords and unattended service accounts. -->

| Setting ID | Requirement |
|---|---|
| SAAS-SET-010 *(Example)* | MFA enforced for all user accounts, including contractors and shared-mailbox delegates |
| SAAS-SET-011 *(Example)* | Phishing-resistant MFA (security keys or platform passkeys) required for all administrators and [finance, HR, executives] |
| SAAS-SET-012 *(Example)* | SMS and voice codes disabled as MFA methods, or allowed only as temporary recovery |
| SAAS-SET-013 *(Example)* | Legacy authentication protocols that cannot do MFA (basic authentication for mail protocols) blocked |
| SAAS-SET-014 *(Example)* | App passwords disabled |
| SAAS-SET-015 *(Example)* | Self-service password reset requires MFA, password rules follow DOC-ISMS-041 (long passphrases, breached-password checks, no forced periodic change without cause) |
| SAAS-SET-016 *(Example)* | Single sign-on from the suite identity to other SaaS where supported, so leavers lose access in one step |
| SAAS-SET-017 *(Example)* | Joiner, mover and leaver changes driven from the HR system, accounts disabled on the last working day (`isms/offboarding-security-checklist`) |
| SAAS-SET-018 *(Example)* | Shared mailboxes (Microsoft 365) have sign-in blocked and are used only through delegation; in Google Workspace use groups or mail delegation instead of shared passwords |
| SAAS-SET-019 *(Example)* | Service accounts inventoried with owner, purpose and credential type, reviewed [quarterly] |

## 5. Conditional access

<!-- Guidance: Conditional access means sign-in decisions based on user, device, location, app and risk. Microsoft 365 calls the feature conditional access; Google Workspace offers context-aware access. Both depend on licence tier. Start in report-only mode where available. -->

```mermaid
flowchart TD
  A["Sign-in request"] --> B{"MFA satisfied?"}
  B -->|No| C["Require MFA"]
  B -->|Yes| D{"Admin role?"}
  D -->|Yes| E{"Phishing-resistant MFA and compliant C1 device?"}
  E -->|No| F["Block"]
  E -->|Yes| G["Allow"]
  D -->|No| H{"Device state"}
  H -->|"Compliant C1 or C2"| G
  H -->|"C3 managed app"| I["Allow in managed apps only"]
  H -->|"Unmanaged browser"| J["Allow web only, no download, print or sync"]
  H -->|"Blocked country or high sign-in risk"| F
```

| Rule ID | Users | Condition | Decision |
|---|---|---|---|
| CA-001 *(Example)* | All | Any sign-in | Require MFA |
| CA-002 *(Example)* | Admins | Any sign-in | Require phishing-resistant MFA and compliant corporate device |
| CA-003 *(Example)* | All | Legacy authentication client | Block |
| CA-004 *(Example)* | All | Device category C3 (DOC-ISMS-058) | Allow only approved managed apps |
| CA-005 *(Example)* | All | Unmanaged device in browser (category C4) | Web access with download, print and sync blocked |
| CA-006 *(Example)* | All | Sign-in from countries where the organization has no staff or business | Block, with exception group for approved travel |
| CA-007 *(Example)* | All | High user or sign-in risk signal (where licensed) | Block or require password change with MFA |

Exclude only the break-glass accounts from conditional access, and alert
on their use.

## 6. External sharing and collaboration

<!-- Guidance: Most suite data leaks are sharing mistakes, not attacks. Decide the default link type and who may share outside, and review public links regularly. Labelling and handling rules come from DOC-ISMS-042. -->

| Setting ID | Requirement |
|---|---|
| SAAS-SET-030 *(Example)* | Default sharing link scoped to specific people, not "anyone with the link" |
| SAAS-SET-031 *(Example)* | Anonymous "anyone" links [disabled / allowed only for named groups with expiry of [30] days] |
| SAAS-SET-032 *(Example)* | External sharing allowed only with authenticated guests, optionally limited to an allow-list of partner domains |
| SAAS-SET-033 *(Example)* | Guest accounts expire after [90] days without activity and are reviewed [quarterly] |
| SAAS-SET-034 *(Example)* | Files labelled Restricted cannot be shared externally (section 10) |
| SAAS-SET-035 *(Example)* | External chat and meeting access limited to approved domains, lobby for external meeting participants |
| SAAS-SET-036 *(Example)* | Automatic forwarding of e-mail to external addresses blocked by default |
| SAAS-SET-037 *(Example)* | Calendar free/busy only, no details, to external users |
| SAAS-SET-038 *(Example)* | Report of externally shared files and public links reviewed [monthly] by data owners |

Transfers of information to external parties also follow the
information transfer policy (DOC-ISMS-043).

## 7. E-mail security and authentication

<!-- Guidance: SPF, DKIM and DMARC protect your domain against spoofing and are now expected by large mailbox providers for bulk senders. DMARC was updated in May 2026: RFC 9989 obsoletes RFC 7489, with reporting moved to RFC 9990 (aggregate) and RFC 9991 (failure). Records still begin with v=DMARC1. RFC 9989 removes the pct tag (percentage roll-out) and adds a t tag for test mode, so stage the roll-out with t=y rather than percentages. Move to an enforcing policy in stages, using aggregate reports to find every legitimate sender first. -->

| Setting ID | Requirement |
|---|---|
| SAAS-SET-050 *(Example)* | SPF record lists every authorised sending service and ends with a fail or softfail qualifier. Keep within the DNS lookup limit |
| SAAS-SET-051 *(Example)* | DKIM signing on for every sending domain, keys of at least 2048 bits, rotated [annually] |
| SAAS-SET-052 *(Example)* | DMARC record on every domain, including parked domains (which publish an SPF record allowing no senders and a reject policy) |
| SAAS-SET-053 *(Example)* | DMARC policy reaches reject within [6] months of start, after aggregate reports show all legitimate senders aligned |
| SAAS-SET-054 *(Example)* | Aggregate reports sent to a monitored mailbox or report-processing service |
| SAAS-SET-055 *(Example)* | Inbound checks of SPF, DKIM and DMARC enforced, external sender tag on messages from outside |
| SAAS-SET-056 *(Example)* | Anti-phishing protections on: impersonation of executives and domains, attachment sandboxing, time-of-click link checks (see DOC-ISMS-059) |
| SAAS-SET-057 *(Example)* | TLS for mail in transit, with MTA-STS and TLS reporting published where supported |

DNS records for the primary domain *(Example, adapt to your senders)*:

```text
example.com.          TXT  "v=spf1 include:[suite SPF include] include:[marketing sender] -all"
selector1._domainkey  TXT  "v=DKIM1; k=rsa; p=[public key from suite admin console]"
_dmarc.example.com.   TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"
```

Staged DMARC roll-out *(Example)*:

```mermaid
gantt
  title DMARC roll-out for the primary domain
  dateFormat YYYY-MM-DD
  section Discover
  Publish p none and collect reports :d1, 2027-01-11, 30d
  Align all legitimate senders :d2, after d1, 30d
  section Enforce
  Quarantine with test flag t=y :e1, after d2, 21d
  Quarantine enforced :e2, after e1, 30d
  Reject :e3, after e2, 30d
```

## 8. Audit logging and alerting

<!-- Guidance: Check that the suite audit log is on (in Microsoft 365 it must be checked, in Google Workspace audit logs are collected by default), how long the licence keeps logs, and whether that covers your investigation needs. Export to central logging if not. Logging rules come from security/security-logging-standard. -->

| Setting ID | Requirement |
|---|---|
| SAAS-SET-070 *(Example)* | Tenant audit log on, including mailbox auditing for all mailboxes |
| SAAS-SET-071 *(Example)* | Sign-in, admin, file sharing and mailbox logs exported to the central log platform or SIEM, retained [12] months or longer |
| SAAS-SET-072 *(Example)* | Alerts for: admin role assignment, break-glass sign-in, new inbox forwarding rule to external address, mass download or deletion, MFA method changes, new third-party app with high-privilege scopes, disabled audit logging |
| SAAS-SET-073 *(Example)* | Alerts routed to security operations with triage times set in the security monitoring procedure (DOC-ISMS-064) |
| SAAS-SET-074 *(Example)* | Suite secure-score or security health report reviewed [monthly] and changes recorded |

## 9. Retention, legal hold and backup

<!-- Guidance: Retention means keeping data for a set time, deletion means removing it when that time ends. Both come from the retention schedule. Native recycle bins are not backups: decide on third-party backup in the backup policy. -->

| Setting ID | Requirement |
|---|---|
| SAAS-SET-090 *(Example)* | Retention policies for e-mail, chat and files match the retention schedule in `data/data-retention-deletion-standard` |
| SAAS-SET-091 *(Example)* | Legal hold capability tested and restricted to legal and named investigators |
| SAAS-SET-092 *(Example)* | Leaver data retained for [90] days, transferred to the manager when the business needs it, then deleted |
| SAAS-SET-093 *(Example)* | Third-party backup of mail, files and sites [in place / not needed, with reason], restore tested [quarterly] per DOC-ISMS-061 and logged in DOC-ISMS-071 |
| SAAS-SET-094 *(Example)* | eDiscovery and content search roles limited and their use logged |

## 10. Data loss prevention and labels

<!-- Guidance: Start DLP with a few high-value patterns (payment card numbers, national identifiers, health data, customer exports) in notify mode, tune, then block. Label names must match the classification scheme. -->

| Setting ID | Requirement |
|---|---|
| SAAS-SET-110 *(Example)* | Sensitivity labels match the classification levels in `data/data-classification-policy` (for example Public, Internal, Confidential, Restricted) |
| SAAS-SET-111 *(Example)* | Restricted label applies encryption or access restriction and blocks external sharing |
| SAAS-SET-112 *(Example)* | DLP rules detect [payment card numbers, health record identifiers, customer data exports] in mail, chat and files, notify the user first, block external sending of Restricted content |
| SAAS-SET-113 *(Example)* | DLP incidents reviewed by [@secops] within [2] business days |
| SAAS-SET-114 *(Example)* | Generative AI assistants in the suite enabled only after the AI usage review (`ai-data/ai-usage-policy`), respecting labels and permissions |

Detailed DLP design is in the data masking and DLP standard
(DOC-ISMS-062).

## 11. Third-party apps and consent

<!-- Guidance: Users granting an app access to their mailbox or files is a common data leak and a known phishing technique (consent phishing). Require admin approval for apps that ask for broad access. -->

| Setting ID | Requirement |
|---|---|
| SAAS-SET-130 *(Example)* | Users cannot grant third-party apps access to organization data, or may grant only low-risk scopes from verified publishers |
| SAAS-SET-131 *(Example)* | Admin consent workflow: requests reviewed by IT and security against the cloud services security policy (DOC-ISMS-044) |
| SAAS-SET-132 *(Example)* | Marketplace add-ins and extensions limited to an allow-list |
| SAAS-SET-133 *(Example)* | Inventory of connected apps and their scopes reviewed [quarterly], unused apps removed |
| SAAS-SET-134 *(Example)* | Domain-wide or tenant-wide delegation granted only to approved service accounts with documented scopes |

## 12. Size tiers

<!-- Guidance: Licence tier often decides which controls exist. Where a feature is not available, record the compensating control rather than leaving the row blank. -->

| Aspect | Small: Quillmere Analytics Ltd | Medium: Quillmere Health Systems | Large: Quillmere Group |
|---|---|---|---|
| Tenant *(Example)* | One tenant, 46 accounts (38 employees, 8 contractors), business-tier licences | One tenant, 320 accounts, enterprise-tier licences | One tenant per legal entity or a single global tenant with regional admin units, 2,400 accounts |
| Administration | 2 highest-privilege admins plus 2 break-glass accounts, Head of Engineering Operations owns the baseline | Delegated roles for helpdesk, security team holds security admin | Regional delegated admins, CISO office owns baseline and reviews |
| Conditional access | MFA for all, admins on phishing-resistant keys, device compliance for admins | Full rule set in section 5 | Full rule set plus per-country location rules and OT jump-host exceptions |
| DLP and labels | Labels plus DLP for customer exports | Labels, DLP for health data and customer exports | Labels per entity, DLP for engineering drawings and personal data |
| Logging | Native audit log reviewed monthly, alerts to managed detection service | Export to SIEM, 12 months | SIEM with SOC, 24 months |

## 13. Review, deviations and records

<!-- Guidance: Quarterly reviews catch new features and drift. Use a scripted export or a posture tool where possible, so the evidence is repeatable. -->

1. IT runs a tenant review against this baseline [quarterly] and after
   major vendor announcements. Findings become tickets with owners and
   due dates.
2. Deviations (a setting not met) are requested with the security
   exception request (DOC-ISMS-122) and recorded below.
3. Changes to tenant-wide settings follow change enablement
   (`ops/change-enablement-policy`).

| Deviation ID | Setting | Reason | Compensating control | Expiry |
|---|---|---|---|---|
| DEV-SAAS-001 *(Example)* | SAAS-SET-013, legacy protocol allowed for 1 scanner mailbox | Office multifunction printer cannot use modern authentication | Mailbox can send only internally, from office IP range, replacement scheduled | 2027-04-30 |

| Record | Owner | Location | Retention *(Example)* |
|---|---|---|---|
| Quarterly tenant review report and configuration export | [@head-of-it] | ISMS evidence folder | 3 years |
| Admin role membership reviews | [@head-of-it] | Access review records | 3 years |
| Conditional access policy exports | [@head-of-it] | Configuration repository | 3 years |
| DMARC aggregate report summaries | [@head-of-it] | Report service or evidence folder | 1 year |
| Alert and DLP incident tickets | [@secops] | Ticketing system | 3 years |
| App consent approvals | [@head-of-it] | Ticketing system | 3 years |
| Deviations | [@isms-manager] | Exception register | Expiry plus 3 years |

Map these records to the controls in the control evidence matrix
(DOC-ISMS-033, `isms/control-evidence-matrix`).

## 14. References

<!-- Guidance: Vendor documentation changes often. Record the date you last checked each admin console path in the setting tables. -->

| Reference | Edition | Use |
|---|---|---|
| ISO/IEC 27001:2022 + Amd 1:2024, https://www.iso.org/standard/82875.html | Current, Amd 1 https://www.iso.org/standard/88435.html | Annex A controls cited in the intro |
| ISO/IEC 27002:2022, https://www.iso.org/standard/75652.html | Current | Control guidance |
| CIS Microsoft 365 Foundations Benchmark | Check the current version | Detailed checklist, cited by name only |
| CIS Google Workspace Foundations Benchmark | Check the current version | Detailed checklist, cited by name only |
| RFC 7208, Sender Policy Framework (SPF) | April 2014 | SPF |
| RFC 6376, DomainKeys Identified Mail (DKIM) Signatures | September 2011 | DKIM |
| RFC 9989, Domain-Based Message Authentication, Reporting, and Conformance (DMARC) | May 2026, Proposed Standard, obsoletes RFC 7489 and RFC 9091 | DMARC policy, tags and policy discovery |
| RFC 9990, DMARC Aggregate Reporting | May 2026, Proposed Standard | Aggregate (rua) reports |
| RFC 9991, DMARC Failure Reporting | May 2026, Proposed Standard | Failure (ruf) reports |
| RFC 8461, SMTP MTA Strict Transport Security (MTA-STS) | September 2018 | Mail transport encryption |
| Vendor admin documentation for Microsoft 365 and Google Workspace | Current online | Exact setting names and licence requirements |

Related templates: `isms/secure-configuration-baseline` (DOC-ISMS-060),
`isms/endpoint-device-byod-policy` (DOC-ISMS-058),
`isms/malware-protection-standard` (DOC-ISMS-059),
`isms/access-control-policy` (DOC-ISMS-041),
`isms/data-masking-dlp-standard` (DOC-ISMS-062),
`isms/backup-policy` (DOC-ISMS-061),
`isms/cloud-services-security-policy` (DOC-ISMS-044),
`isms/information-transfer-policy` (DOC-ISMS-043),
`security/privileged-access-standard`, `security/security-logging-standard`,
`data/data-classification-policy`, `data/data-retention-deletion-standard`,
`ops/access-review`.

## Standard and licence note

Structure aligned with ISO/IEC 27001:2022 + Amd 1:2024 (Annex A controls
cited in the introduction) and ISO/IEC 27002:2022. Control numbers are
cited with short original labels. All requirements, tables and examples
are original and reproduce no text from ISO/IEC standards, CIS
Benchmarks or vendor documentation: obtain the official standards from
ISO (https://www.iso.org/standard/82875.html,
https://www.iso.org/standard/75652.html) or your national standards body.
Microsoft 365 and Google Workspace are named only to describe the two
common suites, not as recommendations. Product features and console
names change: check the current vendor documentation and the current
edition of each reference before use.

Template licence: MIT.