Two architectures, one industry.
Compliance SaaS platforms split into two camps. The first ingests customer data — they collect your policies, your evidence files, sometimes the underlying records they describe — and store it in their environment. The second consumes only configuration metadata — IAM policies, security group rules, audit log structure — and never touches the underlying regulated information.
Both can produce accurate compliance evidence. The difference shows up in the threat model, the liability posture, and what your assessor sees when they ask “where does CUI flow?”
FORCE is in the second camp by design.
Cross-tenant introspection. Read-only OAuth roles. We see your IAM policy structure; we never see the data the policies protect. We see your CloudTrail event metadata; we never see the records the events reference. We see your conditional access configuration; we never see your users' mailboxes.
Your CUI never enters our environment. It doesn't need to. Compliance-as-evidence-of-configuration works without ever touching the regulated content itself.
What this buys you.
Three concrete benefits, in roughly increasing order of importance:
1. Lower attack surface.
Your regulated data is not in our breach radius. If FORCE were ever compromised, your CUI is unaffected — because it was never here. The blast radius of any FORCE incident is bounded to configuration metadata about your environment, not the data your environment holds.
Compare to a platform that ingests customer documents. A breach there exfiltrates the data. A breach here exfiltrates a list of your IAM policy names. Both are bad; one is much worse.
2. Cleaner liability allocation.
DFARS 252.204-7012 imposes specific obligations on entities that handle CUI — incident reporting, FedRAMP Moderate equivalence, encryption requirements, supply chain assertions. Once a vendor handles CUI, they become a covered defense contractor for that data and inherit those obligations. Most commercial SaaS vendors don't hold the authorizations required.
FORCE's License Agreement Section 4A makes this allocation explicit: you remain the sole custodian; we don't become a co-handler with the obligations that come with that. Your DFARS 7012 obligations stay yours; we don't ambiguously co-hold them. If you ever need to flow obligations down to a vendor, you flow them to vendors who actually handle the CUI — your GCC High mailbox, your encrypted file transfer service, your subcontractors. Not your audit platform.
3. Simpler audit story.
Every CMMC L2 assessment includes a CUI flow diagram — “where does CUI enter, how does it move, where does it end up.” The fewer vendors on that diagram, the simpler the assessment.
When your assessor asks where CUI flows, FORCE isn't on the list. We're elsewhere on the diagram — we're the audit platform that describes the flow, not a node in the flow. One fewer vendor on your scope diagram. One fewer vendor whose security posture has to be vetted. One fewer vendor whose contract has to flow down DFARS 7012 obligations.
The four mechanisms that enforce this.
Architectural choice alone is not enough; humans paste things into forms. FORCE backs up the architecture with four enforcement layers:
- Contractual prohibition: License Agreement Section 4A prohibits transmission of regulated information to FORCE through any channel.
- Inbound email detection: 25+ regulated information markings auto-quarantined before reaching support staff.
- Product-channel rejection: every customer input scanned for CUI markings; HTTP 422 if detected, content never persists.
- Inadvertent ingress runbook: documented isolate-and-dispose procedure if anything slips through.
Full mechanism detail at /trust/regulated-info →
When “not handling CUI” would be a problem.
Honest framing: there are use cases where you'd want a CUI-handling platform — content storage, document review, regulated workflow tooling. FORCE isn't the right tool for those. We're an audit platform, full stop. If you need CUI handling, you need a GCC High deployment, an authorized SaaS like Microsoft Purview, or your own ITAR-compliant infrastructure. We can prove your CUI handling is configured correctly without ever touching the underlying data.
What this means for you.
- Your CUI never enters our environment.
- Your DFARS 7012 obligations remain yours; we don't ambiguously co-hold them.
- Your scope diagram has one fewer vendor that handles your regulated content.
- Your liability footprint is bounded to your own decisions, not muddied by vendor handling.
It's a deliberate architectural choice. We chose it because we think it's right. Read License Agreement Section 4A →