Sensitive evidence lives in the approved Wickr and retention boundary. Athena’s SaaS manages sanitized workflow, status, control mapping, and approved conclusions.
Athena's SaaS is not FedRAMP authorized. When Regulated Data Boundary controls are enabled, AWS Wickr Premium serves as the FedRAMP Moderate-authorized collaboration component for sensitive communications and evidence exchange. Athena’s SaaS remains outside the regulated-data boundary and receives only sanitized, non-CUI, non-ITAR, or customer-approved information.
Regulated communications and evidence remain within the approved AWS Wickr and customer-controlled retention environment. Athena Fortify-CMMC stores only approved metadata, opaque references, workflow status, responsibilities, and sanitized conclusions.
No. Athena does not represent Fortify-CMMC as FedRAMP authorized. Athena has intentionally architected CUI and regulated evidence out of its SaaS. For regulated engagements, AWS Wickr is used as the authorized secure-collaboration component only after the applicable offering, region, authorization scope, configuration, and supporting AWS services have been validated. CUI and regulated evidence remain within the approved Wickr and customer-controlled retention environment. Athena manages the CMMC workflow through approved metadata, external references, responsibilities, status, and sanitized conclusions.
This design gives the customer a clear, defensible system boundary: regulated content stays in the approved environment, while Athena manages the work required to prepare for and sustain CMMC assessment readiness.
Athena’s advantage is not a claim that its SaaS is FedRAMP authorized. Athena’s advantage is a deliberately controlled architecture that keeps CUI out of its SaaS while coordinating regulated collaboration through a separately validated AWS Wickr environment. This reduces unnecessary compliance exposure while giving customers a governed, traceable CMMC readiness and evidence-management process.
Regulated content never leaves the customer-controlled AWS boundary on the left. Only sanitized references, mapping, status, and approved conclusions pass the gate into Athena on the right.
How can Athena provide a FedRAMP solution?
It does not, and never claims to. No. Athena does not represent Fortify-CMMC as FedRAMP authorized. Athena has intentionally architected CUI and regulated evidence out of its SaaS. For regulated engagements, AWS Wickr is used as the authorized secure-collaboration component only after the applicable offering, region, authorization scope, configuration, and supporting AWS services have been validated. CUI and regulated evidence remain within the approved Wickr and customer-controlled retention environment. Athena manages the CMMC workflow through approved metadata, external references, responsibilities, status, and sanitized conclusions.
Is this defensible in an assessment?
The C3PAO makes that determination, not Athena. What the arrangement gives an assessor is a narrow, evidenced boundary: regulated content stays in the customer-controlled environment, every release into the SaaS is classified server-side and human-approved, and each refusal and approval is written to an append-only log. The six tests below are what an assessor typically probes, and where the supporting record lives.
Secure collaboration
AWS Wickr (offering recorded per engagement)
Region recorded per engagement
Controlled retention repository
Separately configured customer component
Stays here, always
2 · Sanitization gate
Server-side, fail-closed. Blocked entries are refused and logged.
Human certifier plus a second approver on every release.
Receives only
And does this with it
What an assessor tests — and where the record lives
Is the system boundary drawn and documented?
Boundary profile, this architecture view, and the SSP boundary section
Is the authorization scope of the collaboration component evidenced?
Offering + region + services-in-scope determination, with source reference and validator
Can you show regulated content never entered the SaaS?
Server-side classification gate, fail-closed refusals, and the append-only audit log
Is each release into the SaaS sanitized and human-approved?
Sanitization review records with certifier and second approver
Are the retention repository and its supporting AWS services determined?
Retention stack determinations with evidence reference and accountable owner
Is the arrangement kept current, not just set up once?
Periodic revalidation cadences, annual re-attestation, and currency score
Test 2 is not yet satisfied for this engagement: the authorization scope of the recorded offering and region has not been verified against the applicable AWS services-in-scope listing. Until that determination is on record, no authorization is represented here.
This document describes Athena's use of AWS Wickr as a FedRAMP-authorized component. It does not represent Athena's SaaS or Athena Consulting Group as independently FedRAMP authorized.
The same five steps every piece of regulated evidence follows. Steps 2 and 3 happen entirely inside the customer boundary; only step 4’s approved output is visible to Athena.
Request raised
Athena creates an evidence request with the practice, objective, owner, and due date. No content yet.
Delivered in the secure room
The customer submits the artifact inside the approved collaboration room. The file never touches Athena.
Retained in the repository
The record lands in the controlled retention repository under customer keys, logging, and schedules.
Sanitized and certified
A reviewer records the opaque reference, hash, and a sanitized summary. A second person approves it.
Athena reasons on the reference
Only that approved record enters Athena, where it drives scoring, findings, POA&Ms, and deliverables.
One artifact, six stages. Select a stage to see exactly what changes about the data, which NIST SP 800-171 families apply there, and which records an assessor can pull as proof. Export the whole map — every stage plus the control mapping — as a print-friendly document or PDF for your audit package.
The contractor produces or exports the source artifact (config export, log extract, screenshot, policy) and applies its own marking. No Athena component participates.
Data in
Nothing yet — the artifact originates on contractor-controlled systems.
Data out
Original artifact with full CUI/FCI content, marked at the owner’s classification.
Controls that apply here
Artifacts produced
Never present at this stage
This document describes Athena's use of AWS Wickr as a FedRAMP-authorized component. It does not represent Athena's SaaS or Athena Consulting Group as independently FedRAMP authorized.
Filter by control family, then jump to the exact stage of the flow above that carries it. Families with no stage touchpoint are satisfied at the layer level only.
3.1 Access Control
3.3 Audit and Accountability
3.4 Configuration Management
3.5 Identification and Authentication
3.6 Incident Response
3.8 Media Protection
3.9 Personnel Security
3.12 Security Assessment
3.13 System and Communications Protection
Hosting and Data Residency
Allocated in the layer matrix below; no single stage of the artifact flow exercises it.
10 of 10 families shown · 6 stages in the flow
Three zones, ten systems, one crossing. Select a numbered handoff to see exactly what moves, what is refused, and which side owns the data at that moment.
People
Humans who act on the system. No system-to-system trust.
Control owner
Uploads regulated evidence
Security officer
Approves policy, region, readiness
C3PAO assessor
Receives the audit bundle
Customer regulated boundary
Customer-owned AWS. CUI is created, stored, and retained here — and stays here.
AWS Wickr Premium
E2EE rooms, messages, files
Retention stack
S3 + customer-managed KMS + CloudTrail
Single sanitization gate
GateDeny-by-default, two-person certification
No return path CUI messages and files never flow back into the SaaS.
No return path Retained originals stay in the customer boundary, always.
Athena SaaS (assessment engine)
Receives sanitized, non-CUI assessment records only. Never a CUI system of record.
Intake + AI guard
Classifies, refuses, logs
War Room
Objective scoring, forecasts, handoff lane
Package generator
Issuance ledger + SHA-256 manifest
Provenance snapshots
Immutable, defensibility-scored
Who talks to whom
Single sanitization gate → Intake + AI guard
Customer regulated boundary → Athena SaaS (assessment engine)
What moves
Non-CUI assessment record
The only crossing into the SaaS: reference ID, hash, control mapping, sanitized rationale, two approver signatures.
What never moves
Nothing crosses without a recorded classification decision and second-person certification.
Athena is the assessment engine; AWS Wickr and the customer retention stack are the authorized custodians of regulated data. Only step 4 crosses the boundary, and it carries sanitized, non-CUI assessment records.
Pick something you would actually send during an assessment. The answer below is computed by the same classification gate that runs server-side — not a diagram someone drew.
1 · Where it starts
A message thread discussing how a control is implemented
2 · What the gate decides
This information cannot be entered into Athena's SaaS. Submit and retain it within the approved AWS Wickr and retention boundary. Record only the approved artifact identifier and sanitized status here.
3 · What happens
Stays in the AWS Wickr enclave. Athena records only that the exchange occurred.
4 · Where the original lives
AWS Wickr enclave
Decision recorded under policy boundary-policy-v1. Refusals are logged; the content itself is never copied into the log.
Paste sample text — never real regulated content — and see exactly which rule fires. This runs the same pattern set the server uses to refuse an outbound payload.
110/1200 characters. Nothing here is transmitted or stored — screening happens in your browser.
Refused — 2 rules fired
What a redacted version would look like
Evidence request EV-1042: firewall at [REDACTED: IP address] still exposes the legacy port; see [REDACTED: Vulnerability identifier (CVE)] in the scan.
23 characters removed. In production the payload is refused outright rather than auto-redacted — a human records an approved sanitized summary instead.
Every CMMC program picks one of three models, usually without saying so out loud. Here is the trade each one makes.
Put CUI in the GRC tool
The common shortcut: upload everything and let the platform index it.
Where regulated data lives
Inside a vendor SaaS you do not control
What the SaaS can see
Everything — file bodies, previews, OCR, embeddings
If the tool is breached
Your CUI is in the blast radius
Assessment speed
Fast
What the C3PAO is shown
A vendor you must now justify as in-scope
Keep it fully manual
Air-gapped folders, spreadsheets, and email chains outside any platform.
Where regulated data lives
Under your control, but scattered
What the SaaS can see
Nothing — because there is no platform
If the tool is breached
No tool to breach; custody is unproven instead
Assessment speed
Slow, and it degrades between assessments
What the C3PAO is shown
Whatever someone reassembled by hand
Athena boundary model
AthenaRegulated data stays in your AWS enclave; only sanitized references cross the gate.
Where regulated data lives
Your AWS Wickr enclave and your retention repository
What the SaaS can see
Identifiers, practice mapping, status, approved conclusions
If the tool is breached
No regulated content to lose — the gate has no return path
Assessment speed
Fast, because the sanitized record is machine-usable
What the C3PAO is shown
A continuously maintained, provenance-backed package
Level 2 practices, allocated practice-by-practice across the AWS Wickr enclave, the controlled retention repository, and Athena’s SaaS. Customer configuration and independent validation remain required.
AWS Wickr enclave
0 practices in view
Retention repository
0 practices in view
Athena SaaS
0 practices in view
This document describes Athena's use of AWS Wickr as a FedRAMP-authorized component. It does not represent Athena's SaaS or Athena Consulting Group as independently FedRAMP authorized.
Regulated content, retention, and analysis are separate layers with separate authorizations. Nothing is inherited.
the applicable authorized offering is the intended collaboration component for this engagement in the validated AWS region recorded for this engagement. Its FedRAMP authorization scope for this offering and region has not yet been verified against the applicable AWS services-in-scope listing, so no authorization is represented here. Regulated evidence remains in the customer-controlled boundary regardless. End-to-end encrypted messaging, calling, file transfer, and rooms carry the regulated conversation and the CUI itself.
The controlled retention repository is a separately configured customer component. It is not represented as FedRAMP authorized merely because AWS Wickr is authorized; its authorization boundary must be determined and documented by the customer. Retention is customer-controlled, keyed with customer-managed keys, and evidenced per service — never inherited.
Athena runs the assessment: objectives, control mapping, findings, POA&Ms, SPRS, and the assessor package. It receives artifact identifiers, sanitized status, and approved conclusions — never regulated content.
Message bodies, files, and retained-record content are permanently unsupported capabilities. Content reads are refused before any network call and the refusal is audited.
Vault material is wrapped per user; customers may supply their own key material so the analysis layer never holds a decryptable copy.
Each capability carries a status, the AWS document it came from, and a verification date. Nothing is invoked unless the interface is verified for your deployment.
Mode A (reference-only) ships on. Notification and administrative modes require a recorded Security Officer approval and an in-boundary determination.
Athena records references, statuses, and approvals about the Wickr boundary. It makes no calls to AWS at all. This is the default and the safest posture.
Athena may send sanitized, allowlisted workflow notifications toward the boundary. Payloads are scrubbed and hashed before delivery, and nothing is read back.
Athena calls the verified AWS Wickr admin API from server-side code only, to read configuration and health and to evidence readiness. Credentials never reach the browser.
The same manifest the product enforces at runtime. Only capabilities marked invocable can be called; everything else is documented, not assumed. Last verified 2026-08-05.
| Capability | Status | Invocable | Source |
|---|---|---|---|
Discover Wickr networks Returns network configuration metadata only. No message or file content is exposed by these operations. | Verified API | Yes | AWS Wickr API Reference ListNetworks / GetNetwork |
Read Wickr network settings Configuration posture only. Athena reads settings to evidence readiness; writes stay administrator-assisted. | Verified API | Yes | AWS Wickr API Reference GetNetworkSettings / UpdateNetworkSettings |
Read Wickr user directory Identity metadata only. Used to evidence named-user and device readiness items. | Verified API | Yes | AWS Wickr API Reference ListUsers / GetUser / ListDevicesForUser |
Provision and deprovision Wickr users Available, but gated behind Security Officer approval because deprovisioning is destructive to an active engagement. | Verified API | Yes | AWS Wickr API Reference BatchCreateUser / BatchDeleteUser / BatchToggleUserSuspendStatus / BatchReinviteUser |
Create and update security groups Security-group posture, including burn-on-read and federation settings, is readable and writable through the admin API. | Verified API | Yes | AWS Wickr API Reference ListSecurityGroups / CreateSecurityGroup / UpdateSecurityGroup / ListSecurityGroupUsers |
Register OIDC single sign-on Registration and a dedicated test operation both exist. The client secret must live in AWS Secrets Manager; Athena stores only a reference. | Verified API | Yes | AWS Wickr API Reference RegisterOidcConfig / RegisterOidcConfigTest / GetOidcInfo |
Microsoft Entra ID single sign-on configuration AWS documents configuring an OIDC provider such as Microsoft Entra ID for named-user sign-on. The identity provider sits outside the AWS authorization boundary and is validated separately; Athena records the registration and its test result, never the client secret. | Verified configuration | Yes | AWS Wickr Administration Guide, single sign-on configuration Console-guided or OIDC registration |
Create and manage the data retention bot Bot lifecycle is API-manageable. Athena never receives the bot challenge value or any retained content. | Verified API | Yes | AWS Wickr API Reference CreateDataRetentionBot / GetDataRetentionBot / UpdateDataRetention / DeleteDataRetentionBot |
Serverless data retention (Nitro Enclaves and a customer managed key) Wickr decrypts inside AWS Nitro Enclaves using your customer managed key and writes to an S3 bucket encrypted with that key, read through a provided decryption function. Prefer this over a self-managed container host. | Verified configuration | Yes | AWS Wickr Administration Guide, Data retention modules Console-guided setup |
CloudTrail capture of Wickr API calls Covers Wickr API and console-originated administrative calls. It does NOT cover in-application client events, so audit claims must be scoped to the control plane. | Verified configuration | Yes | AWS Wickr Administration Guide, Logging with CloudTrail CloudTrail trail |
Read Wickr message or file content from the SaaS Every message, call, and file is encrypted with a new random key and no party other than the intended recipients, including AWS, can decrypt it. Athena must never attempt to retrieve content. | Unsupported | No | AWS Wickr Administration Guide, end-to-end encryption |
Deploy a write-only Wickr bot A data retention bot exists precisely to receive all network content. There is no documented read-restricted bot, so a write-only claim cannot be made. | Unsupported | No | AWS Wickr Administration Guide, Data retention modules |
Audit in-application Wickr client events CloudTrail records API activity, not end-user client behaviour inside the Wickr application. | Unsupported | No | AWS Wickr Administration Guide, Logging with CloudTrail |
Deep link directly into a Wickr room No documented deep-link scheme. Until AWS confirms one, the product links to the Wickr application generally and names the room in text. | Pending AWS confirmation | No | Not documented as of the verification date |
FIPS-validated Wickr API endpoint Regional endpoints follow the admin.wickr.{region}.amazonaws.com pattern. A separate FIPS endpoint is not documented, so no FIPS endpoint claim may be made. | Pending AWS confirmation | No | Not documented as of the verification date |
AWS Config inspection of internal Wickr settings AWS Config can record surrounding customer resources such as the retention bucket, key, and roles, but not settings inside the Wickr network. | Unsupported | No | Not documented as of the verification date |
Authorized offering and region determination Authorization depends on the specific offering and region the customer deploys. The customer must confirm scope and attach the evidence; Athena records the determination and never asserts it. | Customer-configured | No | AWS Services in Scope of the FedRAMP program |
This document describes Athena's use of AWS Wickr as a FedRAMP-authorized component. It does not represent Athena's SaaS or Athena Consulting Group as independently FedRAMP authorized.
No. Athena does not represent Fortify-CMMC as FedRAMP authorized. Athena has intentionally architected CUI and regulated evidence out of its SaaS. For regulated engagements, AWS Wickr is used as the authorized secure-collaboration component only after the applicable offering, region, authorization scope, configuration, and supporting AWS services have been validated. CUI and regulated evidence remain within the approved Wickr and customer-controlled retention environment. Athena manages the CMMC workflow through approved metadata, external references, responsibilities, status, and sanitized conclusions. This design gives the customer a clear, defensible system boundary: regulated content stays in the approved environment, while Athena manages the work required to prepare for and sustain CMMC assessment readiness.
Sensitive evidence lives in the approved Wickr and retention boundary. Athena’s SaaS manages sanitized workflow, status, control mapping, and approved conclusions.
No. Capabilities that would read message bodies, file content, or retained-record exports are marked unsupported in the capability manifest and are refused locally, before any request is formed. The refusal is written to the boundary audit log.
The controlled retention repository is a separately configured customer component. It is not represented as FedRAMP authorized merely because AWS Wickr is authorized; its authorization boundary must be determined and documented by the customer.
Verify-before-build. An interface is only invoked once the AWS documentation for it is recorded, the per-tenant capability manifest is verified for the offering and region, and the Security Officer approval is on file.