Google Workspace NIS2 Compliance: Mapping Vault, DLP, and Context-Aware Access to Every Article 21 Measure

Google Workspace runs email, file storage, and day-to-day collaboration for a large share of the organisations now inside NIS2’s scope — and none of its admin console screens will tell you whether that configuration actually satisfies Article 21(2) of the NIS2 Directive. That determination requires reading ten specific measures against your specific settings, and no vendor dashboard does that arithmetic for you.

What follows maps each Google Workspace capability, by name, to the exact numbered Article 21(2) measure it supports — Google Vault, Context-Aware Access, Data Loss Prevention, Client-side Encryption, and Advanced Mobile Management each get their own section — and then draws a hard line under what remains entirely your organisation’s job to document, regardless of how the admin console is configured.

Does Google Workspace Make You NIS2 Compliant? Two Separate Obligations

No single product makes an organisation NIS2 compliant, and Google Workspace is no exception — compliance is a property of your documented risk-management process, not the software running it. Google itself is not a bystander, though: as a cloud computing service provider, it sits inside NIS2’s Annex I digital-infrastructure category, and Google Cloud says so publicly — “as a covered entity, Google Cloud will be responsible for meeting cyber risk management and incident handling requirements under NIS2 while supporting our customers along their compliance journeys” [3]. That’s Google’s obligation, running parallel to — never instead of — your Article 21(2) duty as the customer.

Germany’s BSI, the national competent authority for most German essential and important entities, states the customer-side half plainly: even where IT is completely outsourced, the entity remains personally responsible for the required measures, for verifying its providers implement them, and for the notification duty itself [2]. A Workspace subscription doesn’t shift that burden — it only changes who executes the underlying controls. For the full scope test, see our NIS2 scope test.

The Google Workspace to Article 21(2) Compliance Map

The table below is the core of this guide: which named Google Workspace feature supports which Article 21(2) measure, and — just as importantly — what that feature does not do on its own. Every mapping is checked against Article 21(2)’s own ten sub-points [1], not a reseller’s marketing claim. For the full text of all ten measures in one place, see our Article 21 Decoded guide.

Article 21(2)	Measure	Google Workspace feature	What it actually covers
(a)	Risk analysis & security policies	Workspace Trust / compliance certifications (ISO 27001, 27017, 27018, 27701, SOC 2/3, BSI C5)	Independently audited inherited controls your risk register can cite — not a substitute for that register [9]
(b)	Incident handling	Google Vault (evidence) + Security Investigation Tool / Alert Center (detection)	Preserves Gmail/Drive/Chat evidence under legal hold and surfaces suspicious-activity signals; does not run your response process or file the Article 23 notification [4][10]
(c)	Business continuity, backup, disaster recovery	Google’s own infrastructure redundancy (ISO 22301-certified data centres)	Keeps Workspace itself available; is not your organisation’s documented business continuity plan [3]
(d)	Supply chain security	Cloud Data Processing Addendum & subprocessor disclosures	Gives you the paperwork to add Google correctly to your own supplier register — you still have to build that register [3]
(e)	Acquisition, development & maintenance, incl. vulnerability handling	Google’s own platform patching (outside the admin console)	Covers the Workspace application itself; the full obligation returns to you for anything built on top — Apps Script, add-ons, API integrations
(f)	Effectiveness assessment	Security Investigation Tool, Security Health page, admin audit log	A KPI and evidence trail for periodic review — admin log event data is retained for a fixed 6 months and administrators cannot extend it, so export before then if your policy requires longer retention [12]
(g)	Cyber hygiene & training	Alert Center notices, Advanced Protection Program	Flags risky behaviour after the fact; there is no Workspace-native substitute for a documented, role-based training programme
(h)	Cryptography	Client-side encryption (CSE) + default at-rest/in-transit encryption	Default encryption covers most organisations’ baseline; CSE adds a key layer Google itself cannot decrypt, for the subset of data that needs it [9][11]
(i)	HR security, access control, asset management	Context-Aware Access + Advanced Mobile/Endpoint Management + DLP data-classification rules	Three separate controls covering privileged access, device compliance, and information handling — the most densely covered measure [5][7][8]
(j)	MFA / secured communications	Mandatory 2-Step Verification enforcement (admin accounts) + TLS-secured Gmail/Meet	Google now auto-enforces 2SV for administrator accounts; your organisation still has to decide and document the policy for everyone else [6]

Two measures are the weakest fit for a SaaS suite, worth naming rather than glossing over. Google’s platform patching covers Workspace itself, but the moment your organisation writes a custom Apps Script, publishes an add-on, or wires Workspace into a third-party tool via the API, the full weight of (e)’s vulnerability-handling obligation is back on your own change-management process. And (g)’s training requirement has no Workspace-native equivalent — Alert Center can flag a user after they’ve clicked a phishing link, but it can’t deliver the training that was supposed to stop the click.

Google Vault: Turning Gmail and Drive Into Article 21(2)(b) Incident Evidence

For compliance officers: Vault lets an administrator configure retention rules and legal holds across Gmail, Drive, Chat, and other supported services, then search, export, and preserve that content — including content a user already tried to delete [4]. That detail is what matters for incident handling: Article 23’s 72-hour notification and one-month final report both require reconstructing what happened, and evidence deleted mid-incident is exactly what a Vault hold keeps from disappearing.

For CISOs and IT leads: effort is low-to-medium. Set retention to match the incident-evidence window your own policy defines — Vault ships no default that satisfies (b) by itself — and pair its holds with the Security Investigation Tool, which searches Gmail, Drive, device, and admin-log data together and lets an admin bulk-remediate (delete malicious mail, wipe a device) once a pattern is confirmed [10].

Context-Aware Access, DLP, and Endpoint Management: Closing Article 21(2)(i)

Article 21(2)(i) bundles HR security, access control, and asset management into one measure, and Google Workspace answers it with three separate, independently configurable features rather than one.

Context-Aware Access evaluates authentication strength, device posture, and network or geographic location, then applies one of three reusable access-level templates — Basic, Medium, or High — across Workspace apps, the Admin console, and any connected SAML application [7]. Google positions it explicitly as a zero-trust building block: rather than a binary allow/block decision at login, access is continuously re-evaluated against those signals.

Data Loss Prevention inspects outgoing Gmail, Drive, and Chat content — body text, attachments, headers, subject lines — against predefined and custom detectors, then blocks, warns, or logs a match depending on the rule [5]. Google recommends starting every new rule in audit-only mode before switching to block, since an over-eager rule on day one generates more tickets than security value.

Advanced Mobile Management covers the asset-management third: it can require device encryption, block compromised or non-compliant devices, wipe a device remotely, and require admin approval before a new device accesses organisational data [8]. Effort to configure all three runs medium — CAA levels and DLP rules both need a testing period before enforcement, and endpoint policies need to account for managed vs. personal devices.

Cryptography Without a Key Management Team: Client-Side Encryption and Article 21(2)(h)

Google Workspace encrypts data at rest and in transit by default across every edition, and that baseline is what most organisations’ (h) cryptography policy will point to as evidence. Client-side encryption (CSE) goes further: files, email, Calendar events, and Meet content are encrypted in the user’s browser before reaching Google’s servers, using an external identity provider and key service Google doesn’t control — so Google’s own infrastructure cannot decrypt that content even under legal compulsion [11].

Effort is high, appropriately so: CSE requires standing up an external key-management integration, and it’s only available on Enterprise Plus, Frontline Plus, and Education Standard/Plus. Reserve it for the data your own risk assessment flags as needing a second encryption layer — IP, health records, financial data — rather than a blanket checkbox exercise. For the full requirement, see our encryption and cryptographic controls guide.

What Google Workspace Cannot Do For You

This is the gap most vendor comparison pages skip past. Google’s certifications, Vault, Context-Aware Access, DLP, and CSE all describe the technical side of the shared-fate line — what Google secures and what its admin console can enforce. Article 21(2) asks for that, plus the documented policy and evidence trail proving the control was deliberately designed for your organisation, not just switched on by default.

Google Workspace gives you (configurable)	Article 21(2) still requires (documented)
ISO 27001 / SOC 2 certifications, Security Health page	Written risk assessment methodology and treatment plan — (a)
Vault legal holds and export	Incident notification procedure mapped to the 24h/72h/1-month Article 23 clock — (b)
Default encryption + client-side encryption	Cryptography policy naming approved algorithms and where CSE applies — (h)
Context-Aware Access levels, endpoint policies	Access control policy defining who may request which access level, and why — (i)

Registering with your national competent authority, honouring the Article 23 notification clock, and completing a supplier-security declaration that names Google as a sub-processor are administrative and legal acts. No SaaS configuration performs them for you, no matter how the admin console is set up. For the supply-chain documentation side of this specifically, see our supply chain security guide.

A 30-Day Configuration Checklist by Role

Role	Immediate actions (0–30 days)	Ongoing
CISO / IT lead	Set Vault retention and holds to match your incident-evidence policy; turn on Gmail/Drive/Chat DLP in audit-only mode; configure Context-Aware Access levels for the Admin console and highest-risk apps; confirm Advanced Mobile Management blocks non-compliant devices	Quarterly Security Health review; DLP rule tuning as false positives surface
Compliance officer	Document which Workspace certifications your risk register cites as inherited controls; add the Cloud Data Processing Addendum to your supplier register; draft the cryptography policy that default encryption or CSE will serve as evidence for	Annual re-certification check; rehearse the Article 23 notification timeline before you need it for real
Board / C-suite	Approve the Article 20 cybersecurity risk-management policy; confirm 2-Step Verification enforcement actually covers every admin account, since Google’s rollout targets administrators first, not the whole organisation	Quarterly KPI briefing sourced from Security Investigation Tool exports

Frequently Asked Questions

Does Google Workspace’s ISO 27001 certification satisfy NIS2 Article 21(2)(a) on its own?
No. It documents that Google’s own infrastructure and processes for Workspace have passed independent audit, which your risk register can cite as an inherited control. It is not a substitute for your organisation’s own risk analysis and information security policy, which Article 21(2)(a) requires regardless of which vendor certifications you can point to [9].

Is Google itself regulated under NIS2, separately from its customers?
Yes. As a cloud computing service provider, Google falls inside NIS2’s Annex I digital-infrastructure category, and Google Cloud has publicly acknowledged its status as a covered entity with its own risk-management and incident-handling obligations [3]. That runs in parallel to, and does not substitute for, your organisation’s Article 21(2) duty as a Workspace customer.

Which Workspace feature covers the Article 21(2)(j) MFA requirement?
Google’s mandatory 2-Step Verification enforcement, now rolling out automatically for administrator accounts, with security keys recommended as the strongest available factor [6]. Enforcement is administrator-first: your organisation still has to decide, configure, and document the MFA policy for standard users rather than assume Google’s rollout covers them too.

Conclusion

Ten Article 21(2) measures, and Google Workspace gives you a named, configurable feature for eight of them — Vault for incident evidence, Context-Aware Access, endpoint management, and DLP together for access control and asset management, client-side encryption for cryptography, the Security Investigation Tool for effectiveness assessment, and the platform’s own certifications for the inherited controls a risk register can cite. The two genuine gaps — acquisition/development/maintenance beyond the platform itself, and cyber-hygiene training — need your own process regardless of vendor. None of the eight covered measures are satisfied by simply having the feature turned on: each still needs the policy document, the retention setting matched to your own incident-evidence window, and the access-level decision that turns a configurable capability into evidence a national competent authority will actually accept.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

1. European Union. Directive (EU) 2022/2555 — Article 21: Cybersecurity Risk-Management Measures. NIS-2-Directive.com.
2. Bundesamt für Sicherheit in der Informationstechnik (BSI). FAQ zu NIS-2.
3. Google Cloud. How Google Cloud Can Help Customers Achieve Compliance With NIS2. Google Cloud Blog.
4. Google Workspace. Google Vault: Data Loss Prevention & Retention.
5. Google Workspace Updates. Workspace Data Loss Prevention (DLP) for Gmail Is Now Generally Available.
6. Google Workspace Admin Help. About 2SV Enforcement for Admins.
7. Google Cloud Architecture Center. Secure Apps and Resources by Using Context-Aware Access.
8. Google Workspace Admin Help. Set Up Advanced Mobile Management.
9. Google Workspace. Security Whitepaper — Supporting Compliance Requirements.
10. Google Workspace Admin Help. About the Security Investigation Tool.
11. Google Workspace Admin Help. About Client-Side Encryption.
12. Google Workspace Admin Help. Data Retention and Lag Times.

Related reading: for the full CIR 2024/2690 implementing-regulation breakdown, see the Implementing Regulation guide; for the difference between essential and important entity status, see our essential versus important entities guide.