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
109 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
109 practices in view
Retention repository
109 practices in view
Athena SaaS
109 practices in view
| Level 2 practice | AWS Wickr enclave | Retention repository | Athena SaaS |
|---|---|---|---|
| 3.1.1 Limit system access to authorized users/processes/devices Access Control | Owns Named users, security groups, least privilege, revocation inside the enclave | Shared IAM-restricted administrator access to retained objects | Out of boundary No CUI accounts or sessions; sanitized workflow roles only |
| 3.1.2 Limit access to permitted transactions/functions (RBAC) Access Control | Owns Named users, security groups, least privilege, revocation inside the enclave | Shared IAM-restricted administrator access to retained objects | Out of boundary No CUI accounts or sessions; sanitized workflow roles only |
| 3.1.3 Control CUI information flow Access Control | Owns Named users, security groups, least privilege, revocation inside the enclave | Shared IAM-restricted administrator access to retained objects | Out of boundary Sanitization gate is the only flow path; regulated flows never reach the SaaS |
| 3.1.4 Separation of duties Access Control | Owns Named users, security groups, least privilege, revocation inside the enclave | Shared IAM-restricted administrator access to retained objects | Out of boundary No CUI accounts or sessions; sanitized workflow roles only |
| 3.1.5 Least privilege for privileged accounts Access Control | Owns Named users, security groups, least privilege, revocation inside the enclave | Shared IAM-restricted administrator access to retained objects | Out of boundary No CUI accounts or sessions; sanitized workflow roles only |
| 3.1.6 Use non-privileged accounts for non-security functions Access Control | Owns Named users, security groups, least privilege, revocation inside the enclave | Shared IAM-restricted administrator access to retained objects | Out of boundary No CUI accounts or sessions; sanitized workflow roles only |
| 3.1.7 Prevent non-privileged execution of privileged functions Access Control | Owns Named users, security groups, least privilege, revocation inside the enclave | Shared IAM-restricted administrator access to retained objects | Out of boundary No CUI accounts or sessions; sanitized workflow roles only |
| 3.1.8 Limit unsuccessful logon attempts Access Control | Owns Named users, security groups, least privilege, revocation inside the enclave | Shared IAM-restricted administrator access to retained objects | Out of boundary No CUI accounts or sessions; sanitized workflow roles only |
| 3.1.9 Privacy/security notices (login banners) Access Control | Owns Named users, security groups, least privilege, revocation inside the enclave | Shared IAM-restricted administrator access to retained objects | Out of boundary No CUI accounts or sessions; sanitized workflow roles only |
| 3.1.10 Session lock with pattern-hiding Access Control | Owns Named users, security groups, least privilege, revocation inside the enclave | Shared IAM-restricted administrator access to retained objects | Out of boundary No CUI accounts or sessions; sanitized workflow roles only |
| 3.1.11 Session termination Access Control | Owns Named users, security groups, least privilege, revocation inside the enclave | Shared IAM-restricted administrator access to retained objects | Out of boundary No CUI accounts or sessions; sanitized workflow roles only |
| 3.1.12 Monitor/control remote access sessions Access Control | Owns Named users, security groups, least privilege, revocation inside the enclave | Shared IAM-restricted administrator access to retained objects | Out of boundary No CUI accounts or sessions; sanitized workflow roles only |
| 3.1.13 Cryptographic protection for remote sessions Access Control | Owns Named users, security groups, least privilege, revocation inside the enclave | Shared IAM-restricted administrator access to retained objects | Out of boundary No CUI accounts or sessions; sanitized workflow roles only |
| 3.1.14 Route remote access via managed control points Access Control | Owns Named users, security groups, least privilege, revocation inside the enclave | Shared IAM-restricted administrator access to retained objects | Out of boundary No CUI accounts or sessions; sanitized workflow roles only |
| 3.1.15 Authorize remote privileged commands Access Control | Owns Named users, security groups, least privilege, revocation inside the enclave | Shared IAM-restricted administrator access to retained objects | Out of boundary No CUI accounts or sessions; sanitized workflow roles only |
| 3.1.16 Authorize wireless access prior to connections Access Control | Owns Named users, security groups, least privilege, revocation inside the enclave | Shared IAM-restricted administrator access to retained objects | Out of boundary No CUI accounts or sessions; sanitized workflow roles only |
| 3.1.17 Protect wireless with auth and encryption Access Control | Owns Named users, security groups, least privilege, revocation inside the enclave | Shared IAM-restricted administrator access to retained objects | Out of boundary No CUI accounts or sessions; sanitized workflow roles only |
| 3.1.18 Control connection of mobile devices Access Control | Owns Named users, security groups, least privilege, revocation inside the enclave | Shared IAM-restricted administrator access to retained objects | Out of boundary No CUI accounts or sessions; sanitized workflow roles only |
| 3.1.19 Encrypt CUI on mobile devices Access Control | Owns Named users, security groups, least privilege, revocation inside the enclave | Shared IAM-restricted administrator access to retained objects | Out of boundary No CUI accounts or sessions; sanitized workflow roles only |
| 3.1.20 Verify/limit connections to external systems Access Control | Owns Named users, security groups, least privilege, revocation inside the enclave | Shared IAM-restricted administrator access to retained objects | Shared Athena is itself the external system; connection is limited to sanitized references |
| 3.1.21 Limit use of portable storage on external systems Access Control | Owns No portable-storage path out of the enclave | Shared IAM-restricted administrator access to retained objects | Out of boundary No portable media handling |
| 3.1.22 Control CUI on publicly accessible systems Access Control | Shared Publication review before any content leaves the enclave | Shared IAM-restricted administrator access to retained objects | Shared Sanitization review gates every artifact published to the SaaS |
| 3.2.1 Security awareness for all users Awareness and Training | Shared Enclave-specific handling and secure-handoff training | Supports Retention custodian briefing | Supports Tracks completion and evidences training artifacts |
| 3.2.2 Role-based training for security duties Awareness and Training | Shared Enclave-specific handling and secure-handoff training | Supports Retention custodian briefing | Supports Tracks completion and evidences training artifacts |
| 3.2.3 Insider threat awareness training Awareness and Training | Shared Enclave-specific handling and secure-handoff training | Supports Retention custodian briefing | Supports Tracks completion and evidences training artifacts |
| 3.3.1 Create/protect/retain audit records Audit and Accountability | Owns Administrative and client-event accountability records | Shared Repository access logging and CloudTrail where configured | Supports Audits sanitized, non-CUI workflow events only |
| 3.3.2 Trace actions to individual users Audit and Accountability | Owns Administrative and client-event accountability records | Shared Repository access logging and CloudTrail where configured | Supports Audits sanitized, non-CUI workflow events only |
| 3.3.3 Review and update audited events Audit and Accountability | Owns Administrative and client-event accountability records | Shared Repository access logging and CloudTrail where configured | Supports Audits sanitized, non-CUI workflow events only |
| 3.3.4 Alert on audit processing failures Audit and Accountability | Owns Administrative and client-event accountability records | Shared Repository access logging and CloudTrail where configured | Supports Audits sanitized, non-CUI workflow events only |
| 3.3.5 Correlate audit analysis and reporting Audit and Accountability | Owns Administrative and client-event accountability records | Shared Repository access logging and CloudTrail where configured | Supports Audits sanitized, non-CUI workflow events only |
| 3.3.6 Audit reduction and report generation Audit and Accountability | Owns Administrative and client-event accountability records | Shared Repository access logging and CloudTrail where configured | Supports Audits sanitized, non-CUI workflow events only |
| 3.3.7 Time synchronization for timestamps Audit and Accountability | Owns Administrative and client-event accountability records | Shared Repository access logging and CloudTrail where configured | Supports Audits sanitized, non-CUI workflow events only |
| 3.3.8 Protect audit info from unauthorized access Audit and Accountability | Owns Administrative and client-event accountability records | Owns Object lock and versioning prevent audit-record alteration or deletion | Supports Audits sanitized, non-CUI workflow events only |
| 3.3.9 Limit audit management to subset of privileged users Audit and Accountability | Owns Administrative and client-event accountability records | Shared Repository access logging and CloudTrail where configured | Supports Audits sanitized, non-CUI workflow events only |
| 3.4.1 Establish/configure baselines Configuration Management | Owns Managed network baseline and controlled room configuration | Shared Bucket, versioning, retention, and object-lock configuration | Supports Assessment configuration governed by the approved plan |
| 3.4.2 Track/manage/approve configuration changes Configuration Management | Owns Security configuration enforced by the managed enclave baseline | Shared Bucket, versioning, retention, and object-lock configuration | Supports Assessment configuration governed by the approved plan |
| 3.4.3 Analyze security impact of changes Configuration Management | Owns Managed network baseline and controlled room configuration | Shared Bucket, versioning, retention, and object-lock configuration | Supports Assessment configuration governed by the approved plan |
| 3.4.4 Identify and manage security-relevant changes Configuration Management | Owns Managed network baseline and controlled room configuration | Shared Bucket, versioning, retention, and object-lock configuration | Supports Assessment configuration governed by the approved plan |
| 3.4.5 Define/access control for system components Configuration Management | Owns Managed network baseline and controlled room configuration | Shared Bucket, versioning, retention, and object-lock configuration | Supports Assessment configuration governed by the approved plan |
| 3.4.6 Least functionality (disable unnecessary) Configuration Management | Owns Managed network baseline and controlled room configuration | Shared Bucket, versioning, retention, and object-lock configuration | Supports Assessment configuration governed by the approved plan |
| 3.4.7 Restrict program execution (allowlisting) Configuration Management | Owns Managed network baseline and controlled room configuration | Shared Bucket, versioning, retention, and object-lock configuration | Supports Assessment configuration governed by the approved plan |
| 3.4.8 Change control for system updates/patches Configuration Management | Owns Managed network baseline and controlled room configuration | Shared Bucket, versioning, retention, and object-lock configuration | Supports Assessment configuration governed by the approved plan |
| 3.4.9 Control/limit user-installed software Configuration Management | Owns Managed network baseline and controlled room configuration | Shared Bucket, versioning, retention, and object-lock configuration | Supports Assessment configuration governed by the approved plan |
| 3.5.1 Identify users/processes/devices Identification and Authentication | Owns MFA or approved SSO for all enclave participants | Shared MFA-backed administrator authentication | Supports MFA enforced for SaaS users; no CUI authenticators |
| 3.5.2 Authenticate identities Identification and Authentication | Owns MFA or approved SSO for all enclave participants | Shared MFA-backed administrator authentication | Supports MFA enforced for SaaS users; no CUI authenticators |
| 3.5.3 MFA for privileged accounts Identification and Authentication | Owns MFA required for every enclave participant, privileged or not | Shared MFA-backed administrator authentication | Shared MFA enforced independently for SaaS workflow users |
| 3.5.4 MFA for remote access Identification and Authentication | Owns MFA or approved SSO for all enclave participants | Shared MFA-backed administrator authentication | Supports MFA enforced for SaaS users; no CUI authenticators |
| 3.5.5 MFA for network access to privileged functions Identification and Authentication | Owns MFA or approved SSO for all enclave participants | Shared MFA-backed administrator authentication | Supports MFA enforced for SaaS users; no CUI authenticators |
| 3.5.6 Password complexity Identification and Authentication | Owns MFA or approved SSO for all enclave participants | Shared MFA-backed administrator authentication | Supports MFA enforced for SaaS users; no CUI authenticators |
| 3.5.7 Password change rules (including compromise) Identification and Authentication | Owns MFA or approved SSO for all enclave participants | Shared MFA-backed administrator authentication | Supports MFA enforced for SaaS users; no CUI authenticators |
| 3.5.8 Password reuse restrictions Identification and Authentication | Owns MFA or approved SSO for all enclave participants | Shared MFA-backed administrator authentication | Supports MFA enforced for SaaS users; no CUI authenticators |
| 3.5.9 Protect authenticators Identification and Authentication | Owns MFA or approved SSO for all enclave participants | Shared MFA-backed administrator authentication | Supports MFA enforced for SaaS users; no CUI authenticators |
| 3.5.10 Cryptographically protected authenticators Identification and Authentication | Owns MFA or approved SSO for all enclave participants | Shared MFA-backed administrator authentication | Supports MFA enforced for SaaS users; no CUI authenticators |
| 3.5.11 Obscure authentication feedback Identification and Authentication | Owns MFA or approved SSO for all enclave participants | Shared MFA-backed administrator authentication | Supports MFA enforced for SaaS users; no CUI authenticators |
| 3.6.1 Establish incident handling capability Incident Response | Shared Reporting and escalation path for enclave incidents | Shared Retention anomaly and object-lock violation monitoring | Supports Documented workflow that carries no regulated content |
| 3.6.2 Track/report incidents Incident Response | Shared Reporting and escalation path for enclave incidents | Shared Retention anomaly and object-lock violation monitoring | Supports Documented workflow that carries no regulated content |
| 3.6.3 Test incident response Incident Response | Shared Reporting and escalation path for enclave incidents | Shared Retention anomaly and object-lock violation monitoring | Supports Documented workflow that carries no regulated content |
| 3.7.1 Perform system maintenance (controlled) Maintenance | Supports Managed service; customer performs no host maintenance | Shared Customer-controlled repository maintenance activity | Out of boundary No CUI-bearing systems to maintain |
| 3.7.2 Control tools used for maintenance Maintenance | Supports Managed service; customer performs no host maintenance | Shared Customer-controlled repository maintenance activity | Out of boundary No CUI-bearing systems to maintain |
| 3.7.3 Sanitize equipment removed for off-site maintenance Maintenance | Supports Managed service; customer performs no host maintenance | Shared Customer-controlled repository maintenance activity | Out of boundary No CUI-bearing systems to maintain |
| 3.7.4 Control remote maintenance Maintenance | Supports Managed service; customer performs no host maintenance | Shared Customer-controlled repository maintenance activity | Out of boundary No CUI-bearing systems to maintain |
| 3.7.5 Approve and monitor maintenance activities Maintenance | Supports Managed service; customer performs no host maintenance | Shared Customer-controlled repository maintenance activity | Out of boundary No CUI-bearing systems to maintain |
| 3.7.6 MFA for remote maintenance Maintenance | Supports Managed service; customer performs no host maintenance | Shared Customer-controlled repository maintenance activity | Out of boundary No CUI-bearing systems to maintain |
| 3.8.1 Protect media containing CUI Media Protection | Owns End-to-end encrypted exchange through authorized endpoints only | Owns All retained regulated artifacts live only in the customer repository | Out of boundary Stores sanitized references, never the artifact |
| 3.8.2 Limit access to CUI media Media Protection | Owns End-to-end encrypted exchange through authorized endpoints only | Shared Controlled retained-object handling and disposal | Out of boundary No regulated media stored, cached, or retained |
| 3.8.3 Sanitize/destroy media before disposal Media Protection | Owns End-to-end encrypted exchange through authorized endpoints only | Owns Governed sanitization and disposal of retained objects | Out of boundary No regulated media stored, cached, or retained |
| 3.8.4 Mark media with CUI Media Protection | Owns End-to-end encrypted exchange through authorized endpoints only | Shared Controlled retained-object handling and disposal | Out of boundary No regulated media stored, cached, or retained |
| 3.8.5 Control transport of media Media Protection | Owns Accountability for regulated artifacts during transfer | Shared Controlled retained-object handling and disposal | Out of boundary No regulated media stored, cached, or retained |
| 3.8.6 Encrypt media/devices Media Protection | Owns Cryptographic protection during transport is intrinsic to the enclave | Shared Controlled retained-object handling and disposal | Out of boundary No regulated media stored, cached, or retained |
| 3.8.7 Control use of removable media Media Protection | Owns Removable media is not a supported transfer path | Shared Controlled retained-object handling and disposal | Out of boundary No removable-media interface |
| 3.8.8 Control media on external systems Media Protection | Owns End-to-end encrypted exchange through authorized endpoints only | Shared Controlled retained-object handling and disposal | Out of boundary No regulated media stored, cached, or retained |
| 3.8.9 Backup CUI Media Protection | Owns End-to-end encrypted exchange through authorized endpoints only | Shared Controlled retained-object handling and disposal | Out of boundary No regulated media stored, cached, or retained |
| 3.9.1 Screen individuals prior to access Personnel Security | Shared Prompt account revocation on personnel change | Shared Entitlement review and revocation | Supports SaaS account deprovisioning and role review |
| 3.9.2 Ensure CUI access removed on termination/transfer Personnel Security | Shared Prompt account revocation on personnel change | Shared Entitlement review and revocation | Supports SaaS account deprovisioning and role review |
| 3.10.1 Limit physical access to systems Physical Protection | Supports Inherited from the AWS facility authorization | Supports Inherited from the AWS facility authorization | Out of boundary No physical CUI processing location |
| 3.10.2 Protect/monitor physical facility Physical Protection | Supports Inherited from the AWS facility authorization | Supports Inherited from the AWS facility authorization | Out of boundary No physical CUI processing location |
| 3.10.3 Escort visitors and monitor activity Physical Protection | Supports Inherited from the AWS facility authorization | Supports Inherited from the AWS facility authorization | Out of boundary No physical CUI processing location |
| 3.10.4 Maintain visitor access records Physical Protection | Supports Inherited from the AWS facility authorization | Supports Inherited from the AWS facility authorization | Out of boundary No physical CUI processing location |
| 3.10.5 Control physical access devices Physical Protection | Supports Inherited from the AWS facility authorization | Supports Inherited from the AWS facility authorization | Out of boundary No physical CUI processing location |
| 3.10.6 Enforce safeguarding at alternate work sites Physical Protection | Supports Inherited from the AWS facility authorization | Supports Inherited from the AWS facility authorization | Out of boundary No physical CUI processing location |
| 3.11.1 Periodic risk assessments Risk Assessment | Shared Enclave risk and configuration review during the engagement | Shared Retention configuration risk review | Supports Aggregates sanitized risk findings and forecasts |
| 3.11.2 Vulnerability scanning Risk Assessment | Shared Enclave risk and configuration review during the engagement | Shared Retention configuration risk review | Supports Aggregates sanitized risk findings and forecasts |
| 3.12.1 Periodic assessments of controls Security Assessment | Shared Inherit only controls supported by the applicable authorization | Shared Configuration reviewed and evidenced during the engagement | Supports Produces the assessment record; excluded from the CUI boundary |
| 3.12.2 Develop/Update SSP Security Assessment | Shared Inherit only controls supported by the applicable authorization | Shared Configuration reviewed and evidenced during the engagement | Owns Athena owns POA&M generation, tracking, and closure evidence |
| 3.12.3 Remediate deficiencies (POA&M) Security Assessment | Shared Inherit only controls supported by the applicable authorization | Shared Configuration reviewed and evidenced during the engagement | Supports Produces the assessment record; excluded from the CUI boundary |
| 3.12.4 Plan of Action tracking and update Security Assessment | Shared Inherit only controls supported by the applicable authorization | Shared Configuration reviewed and evidenced during the engagement | Owns Athena authors and maintains the SSP and boundary description |
| 3.13.1 Monitor/Control/Protect communications at boundaries System and Communications Protection | Owns End-to-end encryption for all supported communications | Shared Encryption in transit and at rest for retained objects | Supports TLS-protected sanitized metadata only |
| 3.13.2 Employ security engineering principles System and Communications Protection | Owns End-to-end encryption for all supported communications | Shared Encryption in transit and at rest for retained objects | Supports TLS-protected sanitized metadata only |
| 3.13.3 Separate user and management functions System and Communications Protection | Owns End-to-end encryption for all supported communications | Shared Encryption in transit and at rest for retained objects | Supports TLS-protected sanitized metadata only |
| 3.13.4 Prevent unauthorized transfer via shared resources System and Communications Protection | Owns End-to-end encryption for all supported communications | Shared Encryption in transit and at rest for retained objects | Supports TLS-protected sanitized metadata only |
| 3.13.5 Deny by default, permit by exception System and Communications Protection | Owns End-to-end encryption for all supported communications | Shared Encryption in transit and at rest for retained objects | Supports TLS-protected sanitized metadata only |
| 3.13.6 Use cryptography to protect CUI in transit System and Communications Protection | Owns End-to-end encryption for all supported communications | Shared Encryption in transit and at rest for retained objects | Supports TLS-protected sanitized metadata only |
| 3.13.7 Prevent split tunneling (if remote access) System and Communications Protection | Owns End-to-end encryption for all supported communications | Shared Encryption in transit and at rest for retained objects | Supports TLS-protected sanitized metadata only |
| 3.13.8 Implement key management System and Communications Protection | Owns End-to-end encryption prevents unauthorized disclosure in transit | Shared Encryption in transit and at rest for retained objects | Out of boundary No regulated transmission occurs |
| 3.13.9 Terminate network connections at session end System and Communications Protection | Owns End-to-end encryption for all supported communications | Shared Encryption in transit and at rest for retained objects | Supports TLS-protected sanitized metadata only |
| 3.13.10 Manage/monitor/limit external connections System and Communications Protection | Owns End-to-end encryption for all supported communications | Shared Encryption in transit and at rest for retained objects | Supports TLS-protected sanitized metadata only |
| 3.13.11 Use FIPS-validated crypto where required System and Communications Protection | Owns FIPS-validated cryptography as scoped by the applicable authorization | Shared FIPS-validated encryption for retained objects | Out of boundary No regulated data to encrypt |
| 3.13.12 Control CUI transmission via voice/fax System and Communications Protection | Owns End-to-end encryption for all supported communications | Shared Encryption in transit and at rest for retained objects | Supports TLS-protected sanitized metadata only |
| 3.13.13 Protect collaborative devices System and Communications Protection | Owns End-to-end encryption for all supported communications | Shared Encryption in transit and at rest for retained objects | Supports TLS-protected sanitized metadata only |
| 3.13.14 Separate publicly accessible services from internal System and Communications Protection | Owns End-to-end encryption for all supported communications | Shared Encryption in transit and at rest for retained objects | Supports TLS-protected sanitized metadata only |
| 3.13.15 Detect and prevent unauthorized exfiltration System and Communications Protection | Owns End-to-end encryption for all supported communications | Shared Encryption in transit and at rest for retained objects | Supports TLS-protected sanitized metadata only |
| 3.13.16 Protect CUI in application layer System and Communications Protection | Owns End-to-end encryption for all supported communications | Owns Encryption at rest with immutability for all retained regulated data | Out of boundary No regulated data at rest |
| 3.14.1 Identify and correct flaws (patch mgmt) System and Information Integrity | Shared Managed client integrity and update posture | Shared Object integrity, versioning, and immutability checks | Supports Integrity of sanitized records and provenance manifests |
| 3.14.2 Provide protection from malicious code System and Information Integrity | Shared Managed client integrity and update posture | Shared Object integrity, versioning, and immutability checks | Supports Integrity of sanitized records and provenance manifests |
| 3.14.3 Monitor system security alerts/advisories System and Information Integrity | Shared Managed client integrity and update posture | Shared Object integrity, versioning, and immutability checks | Supports Integrity of sanitized records and provenance manifests |
| 3.14.4 Update malicious code protection mechanisms System and Information Integrity | Shared Managed client integrity and update posture | Shared Object integrity, versioning, and immutability checks | Supports Integrity of sanitized records and provenance manifests |
| 3.14.5 Perform periodic scans of systems/files System and Information Integrity | Shared Managed client integrity and update posture | Shared Object integrity, versioning, and immutability checks | Supports Integrity of sanitized records and provenance manifests |
| 3.14.6 Monitor communications for attack indicators System and Information Integrity | Shared Enclave-side monitoring of participants and traffic | Shared Object integrity, versioning, and immutability checks | Supports Monitors sanitized workflow and boundary-guard denials |
| 3.14.7 Identify unauthorized use of system System and Information Integrity | Shared Managed client integrity and update posture | Shared Object integrity, versioning, and immutability checks | Supports Detects unauthorized sanitization-gate attempts and logs denials |
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.