FORCE// TRUST · REGULATED INFORMATION

How FORCE Handles REGULATED INFORMATION.

Short answer: we don't. FORCE is not authorized to receive CUI, FCI, CDI, ITAR, EAR, or classified information. Four enforcement mechanisms ensure we never start.

Why we don't handle regulated information

FORCE is a SaaS audit platform. Our job is to prove your compliance posture using configuration metadata — IAM policies, security group rules, audit log structure, conditional access configuration, directory memberships. Your regulated content never needs to leave your environment for FORCE to do its job.

Most compliance platforms ingest customer data because their architecture requires it. Ours doesn't.

Lower attack surface

Your regulated data isn't in our breach radius. If FORCE were ever compromised, your CUI is unaffected — because it was never here.

Cleaner liability allocation

You remain the sole custodian. We don't become a co-handler with the obligations that come with that — and that you'd have to flow down to us under DFARS 7012.

Simpler audit story

When your assessor asks 'where does CUI flow?', FORCE isn't on the list. One fewer vendor on your scope diagram.

The four mechanisms that enforce this

Layered defense. If contractual prohibition fails, technical controls catch it. If technical controls miss, the runbook recovers.

Contractual prohibition

License Agreement Section 4A defines “Regulated Information” to include CUI, FCI, CDI, ITAR, EAR, and classified information, and contractually prohibits customers from transmitting it to FORCE through any channel. The clause is explicit, specific, and enforceable. Read Section 4A.

Inbound email detection and quarantine

Our commercial Microsoft 365 tenant has Exchange transport rules that detect 25+ regulated information markings ( CUI//, CONTROLLED, FOUO, EXPORT CONTROLLED, ITAR, EAR, USML, ECCN, NOFORN, and others) in subject lines, message bodies, and attachment contents. Detected messages are routed to a quarantine mailbox accessible only to security personnel, never reach support staff, and trigger an automated reply explaining what happened.

Product-channel rejection

FORCE's evidence upload, configuration import, narrative editor, AI Assistant, support ticket, and POA&M endpoints all run the same regulated-information detection before any persistence. If marked content is detected, the request is rejected with HTTP 422 and a clear explanation. The content is never written to S3, DynamoDB, OpenSearch, or Bedrock. We log the metadata of the rejection (which patterns matched, when, by which tenant) but never the content itself.

Inadvertent ingress runbook

In the rare case that regulated information lands in our environment despite the above — e.g., a customer transmits it via an unmonitored channel, or detection has a gap — our documented runbook activates within one hour. The content is isolated within two hours, returned or destroyed under cryptographic confirmation within four hours, and documented in our incident log. We don't analyze, summarize, or otherwise process the content beyond what's necessary to effect disposition. Customers receive a written confirmation of return or destruction.

What this means for you

Your CUI never enters our environment.
FORCE's breach radius excludes your regulated content.
You remain the sole custodian and decision-maker.
Your DFARS 7012 obligations stay yours; we don't ambiguously co-hold them.
If you ever need to transmit regulated information to a vendor, you do so through your own authorized channel — a GCC High mailbox, encrypted file transfer, etc. — not through FORCE.

What about FORCE itself?

We hold ourselves to the same standards we ask of customers. FORCE is itself CMMC L1 self-attested — we eat our own dog food (FORCE is “Tenant Zero” of the FORCE platform). SOC 2 Type II in 2027. CMMC L2 self-assessment in 2028 if our customer base brings us into CUI proximity (it currently doesn't).