How is Athena different from Secureframe, Strike Graph, Paramify, Risk Cognizance, SMPL-C, or Kiteworks?

Those platforms optimize the contractor's readiness workflow — live SPRS tracking, AI controls dashboards, fast SSP/POA&M drafting, continuous control monitoring, LLM document analysis, or CUI data movement. Athena adds the assessor-facing submission layer that almost none of them ship: SAR narrative drafting, eMASS-ready JSON packaging, OSCAL output, and cryptographic provenance (SHA-256 + chain-of-custody) for every artifact a C3PAO or DIBCAC assessor opens on engagement day.

Does Athena replace Secureframe, Strike Graph, or Paramify?

No — Athena is the assessor-side submission layer that sits on top of whatever readiness GRC you already use. Bring evidence from any tool; Athena drafts the SAR, generates the POA&M with prioritized remediation, scores SPRS, and exports eMASS / OSCAL packages with provenance.

What does Athena export for a CMMC Level 2 assessment?

SAR draft with citations, POA&M with milestone estimates, SPRS scoring package, eMASS-ready JSON, OSCAL package, evidence binder with SHA-256 hashes, and a chain-of-custody manifest signed for the assessor.

Can I configure standard Google Workspace to be CMMC Level 2 compliant?

You can configure Workspace to support many NIST 800-171 controls, but handling CUI typically requires more than the default tier — a CUI-appropriate configuration (e.g., Assured Controls / client-side encryption), careful scoping, and your own policies and evidence. The settings below get the technical controls in place; scope and supplemental measures decide whether CUI can live in Workspace at all.

What evidence should I capture while configuring Workspace?

For each setting, export the configuration (screenshot or report) dated within your freshness window, and reference it in your SSP by control. Examples: the 2SV enforcement policy, the admin-role assignment report, the audit-log export config, Vault retention rules, DLP rules, and context-aware access rules.

How to Configure Google Workspace for CMMC Level 2 (Step by Step)

Updated June 2026 · A hardening guide for DIB contractors running on Google Workspace.

This is the practical, control-by-control hardening pass. Before you start, the honest caveat: configuring these settings supports the controls, but it does not by itself make Workspace authorized to hold CUI. Whether CUI can live in Workspace depends on your scope and a CUI-appropriate configuration — see can you hit CMMC Level 2 on Google Workspace? for that decision. Capture evidence as you go: for each step, export the config (dated) and reference it in your SSP by control.

0. Scope first

Decide what FCI/CUI actually lives in Workspace versus an enclave. Scoping errors are the #1 reason assessments balloon. Document the boundary before you harden anything.

1. Enforce MFA — 3.5.3

Admin console → Security → Authentication → 2-Step Verification: enforce 2SV for all users; require security keys / Authenticator for admins. Evidence: the 2SV enforcement policy + the 2SV enrollment report (Reports). Full detail: 3.5.3 MFA evidence.

2. Access control & least privilege — 3.1.1 / 3.1.2

Use organizational units to scope access; create custom admin roles instead of granting super-admin; apply context-aware access rules (device + user conditions). Evidence: admin-role assignment report, context-aware access rules, OU structure. See 3.1.1 and 3.1.2.

3. Audit logging & retention — 3.3.1

Confirm Admin & security audit logs are on; export logs (BigQuery or your SIEM) and set Vault retention rules to your documented retention period. Evidence: log export config + Vault retention rules. See 3.3.1 audit logging.

4. Monitor for attacks — 3.14.6

Logs alone aren't monitoring. Feed Workspace logs into a SIEM (Chronicle or your platform), add detection rules, and monitor inbound/outbound traffic. Evidence: SIEM source list + detection rules + alert-triage records. See 3.14.6 monitoring.

5. Malicious-code protection — 3.14.2

Turn on Gmail's advanced attachment/link protection (Security Sandbox) for the email entry point, and ensure endpoint EDR covers devices. Evidence: Gmail security settings + EDR coverage report. See 3.14.2.

6. Data protection & sharing — DLP and Drive

Restrict external Drive sharing for in-scope OUs; build DLP rules to detect/limit CUI movement; consider client-side encryption for the most sensitive data. Evidence: DLP rules, sharing-restriction settings, CSE config.

7. Encryption — 3.13.11 (the one that needs care)

This is where Workspace alone often isn't enough: 3.13.11 requires FIPS-validated cryptography for CUI, not just "encrypted." Confirm validated modules/configuration for your CUI-protection paths, and document certificate numbers. See 3.13.11 FIPS cryptography.

Where Workspace alone isn't enough

For CUI, expect to add a CUI-appropriate configuration (e.g., Assured Controls / Workspace for government, client-side encryption), possibly an enclave for some workloads, FIPS-validated cryptography, and all of the policy/procedure controls Workspace can't provide. The technical settings above are necessary but not sufficient on their own.

Evidence checklist

2SV enforcement policy + enrollment report
Admin-role assignments + context-aware access rules + OU structure
Audit-log export config + Vault retention rules
SIEM source list + detection rules + alert-triage records
Gmail security settings + endpoint EDR coverage
DLP rules + Drive sharing restrictions + CSE config
FIPS-validated cryptography evidence (certificate numbers, FIPS mode)

Want this mapped to your tenant — covered vs. gaps, with your SPRS score? Get a Google Workspace CMMC evidence map →

Athena prepares organizations for CMMC Level 2; certification rests with C3PAOs/DIBCAC. Google Workspace is a trademark of Google LLC; Athena is not affiliated with or endorsed by Google. Verify all control facts against NIST SP 800-171 Rev. 2, NIST SP 800-171A, and current CMMC rules.