GovComply Trust Center

Our approach to security

GovComply is engineered around a single defining principle: full per-tenant isolation. Each customer tenant runs in its own dedicated AWS account in the production model, with its own network, database, document storage, encryption keys, identity provider, AI knowledge base, and audit trail. Nothing in the application data plane is shared from one tenant to another.

Security controls are declared in the platform’s infrastructure-as-code (AWS CDK) rather than configured by hand after the fact, so they are provisioned consistently with every tenant on every deployment. Our program rests on a set of mutually reinforcing pillars:

Encryption everywhere

Dedicated per-tenant AWS KMS keys (with automatic rotation) for database, document storage, secrets, and logs — so one tenant’s data is never encrypted under another tenant’s key.

Strong identity & access

A per-tenant Amazon Cognito user pool with advanced security enforced, Authorization Code + PKCE, token revocation, bounded sessions, and role-conditional MFA for privileged roles.

Default-deny authorization

Every protected action passes a default-deny authorization gate; denials are recorded on the audit trail.

Append-only audit trail

Audit entries are written through a single chokepoint that stamps tenant identity from server context, stored in append-only, system-versioned database tables.

Defense-in-depth logging

Per-tenant AWS CloudTrail, VPC Flow Logs, and encrypted operational logs provide infrastructure- and account-level traceability.

GovComply's security program is informed by FedRAMP Moderate-aligned practices on AWS GovCloud, and several controls (such as FIPS-validated endpoints and long log-retention windows) are intentionally held at a stronger posture than that baseline requires. To be clear: this reflects our internal engineering priorities, not a FedRAMP authorization or an independent third-party assessment.

Cloud Infrastructure & Network Security

GovComply runs entirely on AWS GovCloud (US), the AWS partition built for U.S. government and regulated workloads. The platform is provisioned as code with the AWS Cloud Development Kit (CDK), pinned to the GovCloud partition and configured to resolve AWS FIPS 140-validated service endpoints by default. GovComply runs only on AWS GovCloud services, many of which carry their own FedRAMP authorizations held by AWS; those are AWS’s authorizations of the underlying infrastructure, not a certification of GovComply.

AWS GovCloud (US) hosting

GovComply is deployed exclusively to AWS GovCloud (US), the isolated AWS partition designed to host sensitive U.S. government and regulated workloads. There is no commercial-AWS deployment in scope.

The infrastructure-as-code is hard-pinned to the GovCloud partition (aws-us-gov).
A continuous-integration lint gate actively fails any infrastructure code that hardcodes a commercial-partition ARN, so every resource ARN is derived from the deployed partition and no resource can accidentally be created outside GovCloud.

Configured to use AWS FIPS 140-validated endpoints

The platform is configured to use AWS FIPS 140-validated cryptographic endpoints and a FIPS-validated load-balancer TLS policy throughout. The validation belongs to AWS’s underlying cryptographic modules and policies; GovComply selects and consumes those validated endpoints rather than implementing its own cryptography.

The CDK application sets FIPS endpoint resolution globally, and application containers run with FIPS endpoint resolution enabled, directing the AWS SDK to FIPS endpoints for services such as CloudWatch Logs, Secrets Manager, and email delivery.
VPC interface endpoints are pinned to FIPS variants where available (for example, the Secrets Manager and Bedrock runtime FIPS endpoints).
The public HTTPS load-balancer listener is pinned to an AWS FIPS-validated TLS policy that floors connections at TLS 1.2, also negotiates TLS 1.3, restricts to strong cipher suites, and offers post-quantum hybrid key exchange.

VPC network isolation and subnet segmentation

Every tenant receives a dedicated VPC across two Availability Zones. Subnets are segmented by exposure:

Public subnets host only the internet-facing Application Load Balancer.
Private subnets host all application compute. The API and worker services run with no public IP address and reach the internet only through managed NAT gateways.

Traffic to AWS services is kept on private VPC endpoints rather than the public internet wherever possible — including S3 (gateway endpoint), Secrets Manager, Amazon ECR, and the Amazon Bedrock runtime. All network traffic is recorded by VPC Flow Logs delivered to an encrypted CloudWatch Logs group and retained for audit traceability.

Security groups — least privilege

Network access is governed by per-tier security groups that default to deny (no allow-all-outbound). Connectivity is explicitly scoped tier-to-tier:

The load balancer accepts inbound HTTPS (443) from the internet and may egress only to the API tier.
The API tier accepts traffic only from the load balancer, and egresses only to the database, the worker tier, and VPC endpoints.
The database accepts inbound traffic only from the API and worker tiers on the SQL Server port (1433) — it is never reachable from the internet.
The worker tier accepts traffic only from the API tier and reaches AWS services over scoped egress to VPC endpoints.

Compute model and TLS termination

Application workloads run on AWS Fargate (serverless containers) in an ECS cluster with Container Insights enabled. An internet-facing Application Load Balancer fronts each tenant and terminates TLS using an ACM certificate and the FIPS-validated TLS policy described above; plaintext HTTP on port 80 is permanently redirected to HTTPS. A tenant deployed without a valid TLS certificate fails to build rather than serving plaintext — TLS at the edge is mandatory, not optional. The API and worker services auto-scale to provide elastic capacity, and database credentials are injected at runtime from AWS Secrets Manager rather than baked into container images.

Data in transit over the public internet is protected by TLS terminated at the load balancer. Inside the private VPC, traffic between the load balancer and the application containers travels over the tenant’s isolated, non-public subnets.

Data Protection & Encryption

GovComply protects customer data with defense-in-depth encryption that is provisioned automatically for every tenant by infrastructure-as-code. All data at rest is encrypted under dedicated, per-tenant AWS KMS customer-managed keys (CMKs), and all externally reachable data paths are protected by TLS.

Per-tenant customer-managed encryption keys

Every tenant is provisioned with its own set of dedicated AWS KMS customer-managed keys — separate keys for the database, object storage, secrets, and logs. This provides cryptographic separation in addition to resource-level isolation.

Four distinct CMKs per tenant, each with a deterministic, tenant-scoped alias.
Automatic key rotation is enabled on all tenant keys.
Key policies follow least privilege: only the account root (for administration) and the tenant’s own workload execution role may use the key for encrypt/decrypt operations.
Keys are retained on stack teardown by default so that encrypted data remains decryptable across redeployments; only explicitly ephemeral preview environments are configured to destroy keys.

Encryption of stored documents and exports (Amazon S3)

Customer documents (the contract/evidence vault) and generated audit packages are stored in per-tenant S3 buckets hardened by default:

Server-side encryption with the tenant’s KMS CMK on every bucket.
All public access blocked at the bucket level.
TLS enforced for all bucket access, so plaintext requests are denied.
Object versioning enabled to protect against accidental overwrite or deletion.
An explicit bucket policy denies any upload that is not KMS-encrypted and denies uploads attempting public ACLs.
For production tenants, the audit-export bucket additionally uses S3 Object Lock in Compliance mode with a defined retention period consistent with federal audit requirements, giving exported audit evidence write-once-read-many (WORM) immutability at the storage layer.
Uploaded objects are scanned for malware before being released to downstream processing (see Threat Protection below).

Database encryption, backups, and protection (Amazon RDS)

Each tenant runs a dedicated Amazon RDS for SQL Server instance in private subnets, not reachable from the internet:

Storage encryption is always on, using the tenant’s dedicated KMS CMK.
The instance is not publicly accessible and is placed in private, egress-only subnets.
In the production configuration: Multi-AZ high availability, automated backups with retention, and deletion protection are enabled, and the instance is retained on stack teardown. Non-production and preview tenants intentionally relax these durability controls for clean teardown.
Database master credentials are generated into AWS Secrets Manager (encrypted with the tenant’s secrets CMK) and rotated automatically on a schedule; a separate least-privilege application login is used at runtime rather than the master credential.

Encryption in transit

The public load balancer terminates HTTPS on port 443 with an AWS FIPS-validated TLS policy that floors at TLS 1.2, negotiates TLS 1.3, restricts to strong ciphers, and includes post-quantum hybrid key exchange.
Any plaintext HTTP request on port 80 is permanently redirected to HTTPS.
A tenant deployed without a valid TLS certificate fails to build rather than serving plaintext.
Internal AWS service calls use private VPC interface endpoints pinned to AWS FIPS endpoint variants.
Message queues (the contract-ingest queue and its dead-letter queue) are encrypted with the tenant’s KMS CMK so in-flight payloads stay within the tenant’s cryptographic boundary.

Data retention and durability

Retention and durability controls scale with environment criticality. In the production configuration, object storage and databases are retained on teardown and protected by deletion protection and S3 Object Lock, reducing the risk of accidental data loss; object versioning and automated database backups support recovery from accidental change. Non-production and ephemeral preview environments are intentionally configured to tear down cleanly — but the core security controls (KMS encryption, public-access blocking, TLS enforcement, and versioning) remain enabled in those environments regardless.

GovComply operates within AWS GovCloud (US) with automated database backups in the production configuration.

Identity & Access Management

GovComply authenticates every user through Amazon Cognito user pools provisioned per tenant in AWS GovCloud (US), with each deployment serving a single tenant whose Cognito pool is the authoritative tenancy boundary. Sign-in uses the OAuth 2.0 Authorization Code flow with PKCE; the API validates the resulting token on every request and then applies a default-deny, role-based authorization gate.

Identity provider and sign-in

Each tenant is backed by a dedicated Amazon Cognito user pool on the Plus tier.
The browser application (a Blazor WebAssembly single-page app) is registered as a public OAuth client using Authorization Code grant with PKCE only; the implicit and client-credentials grants are disabled, and no client secret is issued to the browser.
Self-service sign-up is disabled — accounts exist only by administrator invitation or directory provisioning.
Token revocation is enabled, and the login surface is configured not to disclose whether a given email is registered.
Refresh, ID, and access tokens use conservative, short-lived expirations consistent with our risk posture.

Token validation and API authentication

Every API request authenticates a Cognito-issued ID token via standard JWT-Bearer validation: issuer match against the per-tenant pool, audience match against the application client, cryptographic signature validation against the pool’s auto-discovered signing keys, token-lifetime validation, and an explicit assertion that the token is an ID token (so an access token cannot be substituted). HTTPS is required for metadata discovery, and the clock-skew tolerance is tightened well below the framework default. The client’s real IP address is recovered only when a request arrives from the trusted load balancer, so audit attribution records the actual client address.

Role-based access control and default-deny authorization

Authorization is default-deny: a request is allowed only when one of the caller’s roles is proven to hold the requested capability; otherwise it is denied and the denial is audited.
Six fixed roles (Admin, Compliance Officer, Reviewer, Approver, Supplier Quality Engineer, Read-Only) map to a catalog of fine-grained, feature-scoped permissions spanning user administration, document handling, contract intake, supplier quality, audit packages, and purchase orders.
Role-to-permission grants live in a database matrix rather than in code, so the permission model can be re-balanced without redeploying the application. The matrix is loaded once into an immutable in-memory cache for constant-time lookups.
The mapping table is system-versioned, retaining every change in a history table, and is mutable only by privileged database migrations: the application’s database principal is granted SELECT and explicitly denied INSERT/UPDATE/DELETE.
Authorization decisions evaluate the union of permissions across all of a user’s roles; unrecognized group memberships are ignored rather than causing errors.

Multi-factor authentication and password policy

MFA is enforced conditionally by role for privileged roles, enforced by a Cognito post-authentication trigger that drives privileged users without an enrolled factor into an enrollment flow. The set of roles requiring MFA is configurable per tenant.
The second factor is TOTP (authenticator app); SMS is disabled.
For SAML-federated users, an identity-provider-asserted MFA is accepted as satisfying the requirement.
Cognito advanced security mode is enforced, providing compromised-credential and adaptive risk detection.

MFA is role-conditional rather than universal; it is not required for all users by default.

Regarding passwords: GovComply follows the NIST SP 800-63B philosophy of length-and-screening over mandated composition rules, paired with Cognito’s advanced-security risk detection and role-conditional MFA.

Enterprise single sign-on (optional)

Tenants may optionally enable enterprise single sign-on via SAML federation. When a tenant supplies identity-provider metadata, the platform attaches a SAML identity provider to the Cognito pool, maps the provider’s email, group, and authentication-method claims, and enables federated sign-in. A pre-token-generation step translates the identity provider’s group memberships into the platform’s in-app roles using a per-tenant mapping. Federation is strictly opt-in per tenant; tenants without it use direct Cognito authentication. The group-to-role mapping fails safe — a missing or malformed mapping resolves to no roles, which the default-deny gate rejects.

User invitation and lifecycle management

Administrators manage their tenant’s directory through an Admin-only API surface: invite users, list users and pending invites, resend or revoke invites, grant or revoke roles, and deactivate or reactivate accounts.
Invitations use a 256-bit cryptographically random one-time token; only its SHA-256 hash is stored, and redemption is anonymous, single-use, and non-enumerating (every failure returns one generic message, so the endpoint never reveals whether an account or invite exists).
Role and lifecycle changes require a justification note recorded on the audit trail, and guardrails prevent demoting or deactivating the last active administrator.
A first-login activation step transparently transitions an invited user from Pending to Active and stamps first-login and last-sign-in timestamps, writing an audit event.
Cognito group membership is kept synchronized with role grants, and deprovisioning removes the user from the Cognito pool.

Hardened HTTP responses

The combined web/API host emits a set of defense-in-depth response headers on every response as the first middleware in the pipeline: Strict-Transport-Security (HSTS, one-year max-age with includeSubDomains), X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy: no-referrer, a restrictive Permissions-Policy, and a Content-Security-Policy.

CSP enforcement mode is configurable per deployment as part of our standard hardening checklist. We do not publish the per-deployment enforcement state or directive set here; customers and prospective customers can request our current browser-security configuration through their account team.

Multi-Tenancy & Tenant Isolation

GovComply isolates each customer with a dedicated, end-to-end stack of AWS resources rather than sharing pooled infrastructure. Isolation is enforced again in software at two layers above the infrastructure: at the API boundary and at the database layer.

Dedicated per-tenant AWS resources

The deployment code iterates over the tenant registry and, for every tenant, creates a distinct, tenant-named instance of each resource:

Network (VPC): a private virtual network per tenant, with database and workload subnets that have no public exposure.
Encryption keys (KMS): four separate customer-managed keys per tenant — database, storage, secrets, and logs — each with automatic rotation enabled and a key policy granting use only to that tenant’s workload execution role.
Database (Amazon RDS for SQL Server): a dedicated instance per tenant, in private subnets, not publicly accessible, encrypted under the tenant’s own key, with credentials held in a per-tenant secret with scheduled rotation.
Document storage (Amazon S3): per-tenant buckets for the document vault, audit-package exports, and the regulatory corpus — each encrypted with the tenant’s key, with all public access blocked and TLS enforced.
Identity (Amazon Cognito): a dedicated user pool per tenant; the pool itself is the tenant boundary.
AI knowledge base: a per-tenant vector store and Amazon Bedrock knowledge base for the tenant’s regulatory corpus, reachable only over the tenant’s private network.

In the production deployment model, a single tenant is the sole occupant of its own AWS account. (Non-production environments — for example shared development stacks — may host more than one tenant in a single account; the one-tenant-per-account guarantee describes the production posture.) Because every resource carries the tenant identifier and is encrypted under keys only that tenant’s role can use, one tenant’s stored data is cryptographically and structurally separated from every other tenant’s.

Tenant resolution and enforcement at the API boundary

GovComply’s production model assigns one tenant per deployment, and that tenant’s Cognito user pool serves as the authentication authority. A validated token’s issuer and signature already prove the caller belongs to this deployment’s tenant — a token issued for one tenant’s pool is rejected by another tenant’s API.

On each authenticated request, middleware stamps the deploy-configured tenant identifier (not a user-supplied claim) into the request context, and a policy requires every protected endpoint to carry a valid authenticated session. Unauthenticated requests receive no tenant context, which causes downstream data access to default to denying all rows. The codebase retains an explicit comparison seam so that a future multi-tenant-per-deployment mode could resolve and compare the expected tenant per request.

Per-tenant data segregation in the database

Beyond dedicated databases, GovComply applies an automatic tenant filter inside the data-access layer. Every tenant-owned entity is configured with a global query filter that constrains results to the current request’s tenant; this filter is compiled into the query and applied transparently to all reads, including reads that traverse related records. The current tenant value is supplied by a request-scoped tenant context — derived from the validated token’s pool on the API side, and from the originating message’s tenant attribute on the asynchronous worker side.

This means a developer cannot accidentally write a query that returns another tenant’s data: even a lookup by primary key is silently scoped, so an identifier belonging to a different tenant simply returns nothing. The pattern is applied consistently across the contract, clause, supplier, audit, purchase-order, and compliance data sets. This is an application-layer query filter combined with dedicated per-tenant databases — defense-in-depth, rather than a database-engine row-level-security policy.

Production-versus-non-production data lifecycle

Each tenant is marked as production or non-production. This setting defaults to production when unspecified, so an omitted value fails safe to the strictest data-protection posture. For production tenants, the platform retains data-bearing resources on teardown, enables deletion protection and Multi-AZ on the database, and applies WORM (Object Lock) retention to the audit-export bucket. Non-production tenants explicitly opt into a teardown-friendly posture. Crucially, the security-relevant controls — encryption with customer-managed keys, blocking of public access, TLS enforcement, and object versioning — remain enabled regardless of the production flag; only destroy-blocking and high-availability settings are relaxed for non-production tenants.

Application Security & Secure Development Lifecycle

GovComply is built through an automated, security-by-design software delivery pipeline. Every proposed change moves through deterministic continuous-integration gates before it can merge. The guiding doctrine is “programmatic gates first” — security requirements are enforced by code that fails the build, not by reviewer goodwill, so the same checks apply uniformly to every contribution regardless of author.

Secret scanning on every change

Every pull request is scanned for leaked credentials by a dedicated secret-detection scanner. The scan runs unconditionally on all pull requests — the path filter that limits other checks is deliberately dropped for the security gates.

Findings are redacted in CI logs so the scanner never echoes a matched secret value.
The scanner version is pinned and its download is checksum-verified before use, so the scanning tool cannot be silently swapped by a supply-chain attack.
The rule set is exercised by intentional pass/fail fixtures, so a regression that blinds the scanner is itself caught by the build.

Exact dependency and version pinning (supply-chain hardening)

A deterministic CI gate rejects any floating dependency reference across the entire codebase. The rule: the version that ships must be the exact version a reviewer typed, so a malicious package version published after a pull request is opened cannot enter the pipeline on the next CI run.

NuGet packages must declare an exact version — ranges, wildcards, and missing version attributes are rejected.
Third-party GitHub Actions must be pinned to a full commit SHA or an exact three-part version tag — major-only tags, branches, and @latest are rejected.
Command-line tools installed in workflows must be pinned to an exact version.
The .NET SDK version must be an exact three-part version.
Direct binary downloads must verify a published SHA-256 checksum before installation.

This gate scans workflow files and all project files repository-wide, so version-pinning discipline covers both the build machinery and the product code.

Dependency vulnerability scanning

A dependency-vulnerability gate is in place: a CI job runs dotnet list package --vulnerable and fails the build when a dependency carries a known vulnerability at or above a configurable severity threshold, with a deliberately vulnerable fixture verifying on every run that the scanner is actually tripping. This gate is being extended to cover all product solutions; today it does not yet scan the full product dependency set, so we do not represent every product dependency as CVE-scanned on every change. (Exact version pinning, described above, is enforced repository-wide and does cover the product code.)

Least-privilege CI identity — short-lived tokens, no static credentials

All cross-job and cross-repository automation authenticates as GitHub Apps, never personal access tokens. App installation tokens are short-lived, minted at job runtime, automatically revoked when the job ends, and never written to disk.

Tokens are scoped per repository, narrowing access to only the repos a given job needs.
A deterministic gate fails the build if any token-mint step omits a repository scope or requests a repository outside its declared role boundary (fail-closed).
App private keys are stored once in the smallest scope possible as encrypted CI secrets, never committed to any repository.

For AWS access, no long-lived AWS access key exists anywhere in our CI/CD or deployment pipeline. AWS-touching workflows assume an IAM role via GitHub OIDC, receiving a short-lived credential, and a deterministic gate fails any workflow that wires in a static access key. Production deployments run only in environments configured with required human reviewers, and the customer-facing deploy repository has zero AI-agent installations, so no automated agent can drive a production or customer deployment.

Automated security review of shipped code

Beyond the deterministic gates, an automated review stage assesses every candidate change for output-integrity concerns before it can proceed. The review targets OWASP-class issues: hardcoded secrets, injection vectors, authentication and access-control gaps, weak cryptography, and sensitive-data exposure in logs or errors. This review layer is an AI-assisted assessment that complements — rather than replaces — the deterministic scanners; the hard, machine-enforced floor remains the secret scan, the version-pinning gate, and the dependency gate. Workflow files (the pipeline’s own execution environment) are protected by CODEOWNERS and branch protection requiring human code-owner review.

Threat Protection, Malware Scanning & AI Data Governance

GovComply scans every document uploaded to the contract vault for malware before it enters the compliance workflow, and runs its AI features inside the customer’s own AWS GovCloud (US) account boundary using Amazon Bedrock.

Uploaded-document malware scanning

Every file uploaded to the document vault is scanned for malware before GovComply processes it:

Scanner: Amazon GuardDuty Malware Protection for S3, enabled per tenant.
Clean-gate enforcement: only files confirmed clean are released into the parsing/validation pipeline; downstream processing independently verifies a document’s scan status before acting on it.
Threat handling: files found to contain threats are isolated and rendered permanently inaccessible to the application, and the event is logged for operational visibility.
Fail-closed posture: if a file cannot be scanned, it is rejected rather than passed through unscanned, and scan failures alert an operator rather than failing silently.
In-boundary scanning: scanning occurs entirely within the tenant’s own GovCloud account; document bytes are never sent outside the tenant’s boundary to be scanned.

Malware scanning applies to the document vault (contract, evidence, and purchase-order documents).

AI inference runs inside the tenant’s GovCloud account

GovComply’s AI features (clause extraction, gap detection, evidence validation, flowdown analysis) run on Amazon Bedrock within the customer’s GovCloud (US) AWS account:

Partition and region pinning: The infrastructure targets the aws-us-gov partition, resolves AWS service calls to FIPS endpoints, and scopes Bedrock access to the GovCloud regions.
Models: Deep-analysis tasks use Anthropic Claude on Amazon Bedrock; embedding for the knowledge base uses Amazon Titan Text Embeddings. The model set is declared in a single in-code manifest, and a deploy-time check verifies access to each model so a missing grant fails the deployment rather than surfacing at a customer’s first upload.
Invocation pathing: Models are invoked by the tenant’s own execution role against Bedrock in-region, through a GovCloud inference profile.

Regarding model training: GovComply keeps inference in-account and in-partition, and the codebase does not implement any pathway that copies tenant documents to an external service for model training. Whether the underlying Amazon Bedrock service uses inputs for model training is governed by AWS Bedrock’s own data-handling terms, not by a control GovComply implements — customers should refer to AWS Bedrock service terms for that commitment.

Per-tenant knowledge bases and data isolation

Each tenant has an isolated regulatory knowledge base used to ground clause analysis:

Dedicated per-tenant resources: a per-tenant regulatory-corpus S3 bucket, a per-tenant Amazon Bedrock Knowledge Base, and a per-tenant Amazon OpenSearch Serverless vector collection.
Customer-managed encryption: the corpus bucket and the vector collection are encrypted with the tenant’s own KMS key; buckets enforce TLS, block all public access, and are versioned.
Network isolation: the vector collection denies public access and is reachable only through the tenant’s VPC endpoint, with a narrow carve-out for the Bedrock service principal so the managed knowledge base can index.
Scoped access: IAM grants for retrieval and ingestion are scoped to the specific tenant’s knowledge-base and vector-collection resources.

AI usage logging and prompt-injection hardening

Per-call audit events: each AI extraction emits a start event and exactly one terminal success/failure/refusal event through the central audit writer. The audit payload records a hash of the assembled prompt, the model identity, token counts, latency, and outcome — it deliberately does not store the document text or the model’s output.
Usage metering: per-tenant AI spend, run count, and concurrency are tracked with configurable monthly caps and a per-tenant concurrent-run limit, surfaced in an Admin “AI usage” console, with cap changes themselves audited.
Prompt-injection hardening: untrusted document text is wrapped in delimiters at a single prompt-assembly chokepoint and framed as data rather than instructions, any embedded delimiter tags in the untrusted text are neutralized, schema-bearing extractions force structured output, and an input-size budget fails oversized prompts before any model call. These are defense-in-depth hardening measures, not an absolute guarantee against all prompt-injection attacks.

Auditability, Logging & Monitoring

GovComply maintains a defense-in-depth audit and logging posture spanning three layers: an append-only application audit trail, AWS CloudTrail for infrastructure- and account-level activity, and centralized, encrypted, retention-bound operational logging with automated alarms.

Append-only, tamper-resistant application audit trail

Every audit-relevant action in a tenant’s runtime is recorded as a row capturing the acting user, the actor’s role, the event type, the affected objects, a structured payload, source IP, user agent, and a server-stamped UTC timestamp. Tamper-resistance is implemented through two concrete, reinforcing layers:

System-versioned (temporal) tables. The audit table is declared with SQL Server system-versioning, pairing it with an engine-maintained history table; the database engine rejects UPDATE/DELETE against the history table while versioning is enabled, so the live log is append-only by design.
Explicit grant denials. The provisioning migration issues DENY UPDATE, DELETE on the primary audit table and DENY INSERT, UPDATE, DELETE on the history table to the application database principal. A SQL Server DENY overrides any broader write grant, so the application’s own database account cannot modify or remove audit rows.

These controls bind the application database principal and the SQL engine’s versioning behavior; they make the trail append-only and tamper-resistant with respect to the application. They do not purport to make the trail immutable against every possible actor, such as a privileged database administrator operating outside the application principal.

Two further properties support attribution integrity:

Server-resolved attribution. Tenant identity is always resolved from the authenticated request context, never accepted from the caller, making cross-tenant audit pollution structurally impossible at the write path. System-initiated events are stamped with a reserved system-actor identity.
Single write chokepoint. All features write through one audit-writer interface rather than inserting directly, centralizing the anti-spoofing and integrity guarantees. On failure paths, payloads record fixed exception classifications rather than raw error text, keeping sensitive fragments out of the record.

Comprehensive, versioned event taxonomy

The audit trail uses a closed, append-only taxonomy of well over one hundred named event types covering authentication, document handling, AI extraction and validation, user lifecycle and role changes, authorization denials, regulatory-corpus ingestion, supplier-quality workflows, purchase-order line compliance, and audit-package generation. Event-type semantics are stable, so downstream filters and dashboards can rely on them over time. Authorization denials are themselves audited — the authorization gate writes a denial row on every refusal.

AWS CloudTrail — infrastructure-level audit

Each tenant is provisioned with its own AWS CloudTrail trail capturing management events plus S3 and Lambda data events:

Log file validation is enabled, allowing detection of tampering with delivered log files.
Encryption at rest uses a per-tenant customer-managed KMS key for both the S3 destination and CloudWatch Logs delivery.
In the production configuration, the CloudTrail S3 bucket enables Object Lock in Compliance mode with a defined retention period consistent with federal audit requirements, alongside versioning, full public-access blocking, and enforced TLS. Non-production environments relax Object Lock so development stacks can be torn down cleanly.

These CloudTrail trails capture management and data events within the tenant's account; global service events are outside their scope.

Write-once audit-package evidence storage

Generated audit-package artifacts are written to a per-tenant S3 audit-exports bucket. In the production configuration this bucket enables Object Lock in Compliance mode with a defined retention period consistent with federal audit requirements, plus KMS encryption, versioning, public-access blocking, and enforced TLS — giving exported audit evidence WORM immutability at the storage layer. The application issues short-lived pre-signed download URLs; immutability is enforced as a storage-bucket property rather than in application code.

Encrypted, retention-bound operational logging and monitoring

Application and background-worker logs are written to dedicated CloudWatch Logs groups, encrypted with per-tenant customer-managed KMS keys and configured with a defined retention period consistent with federal audit requirements; production log groups are retained on teardown. The platform wires CloudWatch metric filters and alarms over key subsystems — for example, the regulatory-corpus ingestion pipeline defines alarms for ingestion failures, a run-not-completed watchdog, a critical-log alarm, and a persistently-failing-refresh alarm, and the document-scan path publishes custom metrics. Monitoring is currently strongest around the ingestion and document-scan subsystems and is being broadened over time.

Compliance & Regulatory Alignment

GovComply is purpose-built for the U.S. defense-contracting compliance environment. It is important to separate two distinct things: the regulatory domain the product helps customers manage, and the platform’s own security posture and design alignment.

Built for the defense-contracting regulatory environment

GovComply’s core function is to help defense manufacturers and their suppliers manage federal-acquisition compliance:

FAR / DFARS / CAS clause coverage. The regulatory engine ingests the authoritative public text of all three regulation families directly from the public eCFR (Title 48 — FAR Chapter 1, DFARS Chapter 2, CAS Chapter 99), with a daily refresh so clause text stays current.
DFARS 252.204-7012 and CUI workflows. The product models cybersecurity-flowdown obligations, including subcontractor acknowledgment tracking and readiness signals.
Audit-evidence generation. GovComply produces sign-off-tracked, WORM-finalized audit packages designed to support DCAA/DCMA review windows.

These regulations (FAR, DFARS, CAS, DFARS 252.204-7012) describe the compliance domain the product helps customers manage. They are not attestations about GovComply’s own infrastructure, and using the product does not by itself satisfy a customer’s regulatory obligations on their behalf.

Deployed on AWS GovCloud (US), architected for CUI workloads

GovComply launches and operates entirely within AWS GovCloud (US). This is deliberate: GovCloud is the AWS partition designed to host workloads handling Controlled Unclassified Information (CUI) under DFARS 252.204-7012 and NIST SP 800-171, which a commercial-partition deployment is not intended to satisfy. GovComply is architected to support these CUI requirements; the platform is the hosting and tooling environment, and meeting the controls remains a shared responsibility within the customer’s own authorization boundary.

FIPS-validated endpoints and TLS

The platform is configured to use AWS FIPS 140-validated cryptographic endpoints and a FIPS-validated load-balancer TLS policy. The CDK application enables FIPS endpoint resolution, VPC interface endpoints are pinned to FIPS service variants, and the internet-facing load balancer pins a FIPS-validated TLS policy (TLS 1.2 floor, TLS 1.3 negotiated, strong ciphers, post-quantum hybrid key exchange). FIPS validation applies to the AWS endpoints and TLS policy the platform consumes; GovComply itself has not undergone FIPS 140 module validation.

Encryption, isolation, and audit alignment

Encryption at rest with per-tenant KMS customer-managed keys (automatic rotation enabled) across RDS, S3, SQS, Secrets Manager, and CloudWatch Logs.
Tenant silo isolation. In the production model, each tenant is the sole occupant of its own AWS account; database, storage, KMS keys, Cognito user pool, and retrieval knowledge base are all per-tenant.
Append-only audit trail persisted in SQL Server system-versioned tables with INSERT-only plus DENY UPDATE/DELETE grants to the application principal.
WORM evidence storage for production tenants via S3 Object Lock in Compliance mode.
Traceability via per-tenant CloudTrail (with log-file validation), VPC Flow Logs, and CloudWatch log groups retained for a defined period consistent with federal audit requirements.

FedRAMP-aligned practices (not an authorization)

GovComply's controls are informed by a FedRAMP Moderate baseline as an internal engineering reference point, with several controls (FIPS endpoints, long log-retention windows) intentionally held at a stronger posture. This reflects internal engineering priorities recorded in the project’s design records — it is not a FedRAMP Authorization to Operate (ATO), nor an independent third-party assessment. GovCloud account provisioning and authorization activities are ongoing as part of GovComply's compliance program.

Responsible Disclosure & Contact

We welcome reports from security researchers and customers who believe they have found a vulnerability in GovComply.

Reporting a vulnerability: Email security@govcomply.ai. We treat all security reports as confidential.
Scope: This policy covers the GovComply application and the AWS GovCloud infrastructure described on this page. It does not cover third-party services we depend on (e.g., AWS itself) — please report those directly to the vendor. Social engineering, physical-security testing, and denial-of-service testing against production tenants are out of scope.
What to include: a description of the issue, the affected component or URL, the steps to reproduce it, and any relevant proof-of-concept detail. Please avoid accessing, modifying, or exfiltrating any customer data beyond what is strictly necessary to demonstrate the issue.
Our commitment: we will acknowledge legitimate reports within 1–3 business days, provide a remediation timeline, keep you informed of progress, and will not pursue legal action against good-faith research conducted within this scope and in accordance with this policy.
Disclosure timing: we ask for a reasonable opportunity to investigate and remediate — typically 90 days — before any public disclosure, and are happy to discuss timing on a case-by-case basis for complex issues.

How GovComply protects your data