The regulation requires a CRM. We’re going further.

A request to Garde1 passes through five named control stages before it ever touches your data — and every change leaves an audit record on the way out. Each stage groups the controls that operate there.

1 — Edge

Foreign actors and bots blocked at the network edge, before they reach the application. All inbound traffic terminates at Amazon CloudFront over TLS 1.2_2021 minimum with HTTP/3 (QUIC) negotiation enabled across every distribution (api, app, marketing); viewer protocol policy is redirect-to-https. AWS WAFv2 is attached at the CloudFront tier with managed AWS rule sets — AntiDDoS, Common, Known Bad Inputs — and AWS Bot Control. A U.S.-only geo allowlist drops requests from foreign IP ranges before they cross the CDN. Nothing reaches the application that hasn't already survived all of these.

2 — Identity

Entra OIDC, Garde1-side MFA, NIST-aligned session bounds. Authentication flows through Microsoft Entra External ID over OIDC. Garde1 is an Official Microsoft Partner — a vetted, verified entity in the Microsoft Partner Network with legal, tax, address, and code-of-conduct verification on file and recurring reattestation. SAML and SCIM federate into Entra; Garde1 itself speaks only OIDC. A Garde1-side gate enforces TOTP, WebAuthn passkeys, or single-use backup codes between Entra success and a session token being issued — independent of whether the OIDC provider asserted MFA. Session bounds align with NIST 800-171A AC.L2-3.1.5/.10/.11: access tokens last 15 min, refresh tokens 7 days, SIF max session 8 hours, idle timeout 30 min.

3 — Tenancy

Two-layer tenant isolation, scoped task IAM, secrets in Secrets Manager. Once a session token is valid, every API call is tenant-scoped at two independent layers, and a query has to satisfy both to return data:

1. Application layer. A typed query builder injects the caller's organization filter from the authenticated session — code paths cannot construct a cross-tenant query.
2. Database layer. Postgres row-level security is forced on roughly 110 multi-tenant tables — cross-tenant reads are impossible at the engine level even if a bug bypassed the application layer.

ECS tasks use scoped IAM roles; production credentials live in AWS Secrets Manager — never in code, never in committed environment files.

4 — Data

Validated on ingest, PII-minimized at the boundary, encrypted at rest with customer-managed KMS. When connector evidence arrives, the ingest pipeline runs in this order before anything reaches durable storage:

1. Authenticate the source. Connector run token is verified and tied to the originating organization.
2. Validate the payload. Schema-checked against the vendor + control mapping. Anything that doesn't match the expected shape is rejected.
3. Minimize PII. Display names, personal device identifiers, non-administrator user identifiers, and end-user email addresses are dropped or hashed unless a specific control requires them.
4. Tenant-tag and snapshot. The minimized evidence is stamped with the customer's organization identifier and written behind the same row-level security that gates every other read.

At rest, every store is AES-256. The primary database (Aurora PostgreSQL Serverless v2) is encrypted with a customer-managed KMS key — not the default AWS-managed one — so the encryption boundary is auditable end to end. S3 buckets enforce aws:kms or AES-256 depending on data class; public-access blocks are forced on. A separate application-layer AES-256 key encrypts high- sensitivity values (vendor API tokens, MFA secrets, backup codes) before they reach the database — so even a full database compromise doesn't hand over connector credentials.

5 — Trail

Immutable audit log, PITR backups, public status. Every state-changing action streams through a change-data-capture pipeline into a dedicated audit store with 365-day TTL and point-in-time recovery enabled. Records are immutable for the retention window — there is no UPDATE path on the audit table — and capture the actor, timestamp, prior + new values, IP, user agent, and the related workflow / control / document. Aurora has 35-day automated backups with PITR to any second; the customer documents bucket has S3 versioning on; deletion protection is enabled on both the database and the audit-log table. The status of every monitored endpoint and worker is public, in real time, at status.garde1.com.

This is the distinction buyers care about most. Building blocks — the AWS services Garde1 runs on — are individually FedRAMP Moderate authorized today. The full-system package goes through its own FedRAMP 20x authorization on the roadmap. Until then, the stack gives DIB customers the strongest commercial-region posture available without leaving the FedRAMP service catalog at any layer.

Concretely, every service in Garde1's production AWS stack appears on the AWS FedRAMP services-in-scope list:

Each phase below has a defined trigger, a measurable outcome, and a published date. Shipping each one is how we prove our security posture isn't aspirational.

1. Phase 1Today

   FedRAMP Moderate AWS, US-only region

   The platform runs on FedRAMP Moderate AWS in a US-only region. Your data is encrypted with keys you control, the database physically can't return another customer's rows, every sign-in goes through Microsoft Entra plus a second factor (authenticator app or passkey), vendor API tokens are encrypted with keys that never live in the database, and every action lands in a year-long tamper-evident activity log. Garde1 never asks for or holds CUI — these controls protect your scope, evidence, and connector credentials.

2. Phase 2Planned

   AWS GovCloud (US) tenancy

   A dedicated aws-us-gov partition deployment for customers whose contracts demand U.S.-person-only operator access and a GovCloud-resident control plane. Identity federates through Microsoft Entra Government — every component sourced from the FedRAMP High catalog.

3. Phase 3Planned

   FedRAMP 20x authorization

   Full-system authorization through the streamlined FedRAMP 20x process. The GovCloud tenancy from Phase 2 is the assessment boundary; the building blocks are already authorized. This phase wraps the composed platform in its own package.