Compliance and regulatory mapping

DevSafe's architecture makes compliance easier by keeping your data, your keys, and your storage under your direct control. This page maps DevSafe's security properties to common regulatory frameworks.

SOC 2 Type II

SOC 2 evaluates systems against five trust service principles: security, availability, processing integrity, confidentiality, and privacy. DevSafe's architecture maps cleanly to these principles because the data boundary is controlled by the customer, not by HXA Labs.

Trust principle mapping

Designated-verifier audits

When your auditor needs evidence that backups are intact, DevSafe provides designated-verifier proofs. These proofs demonstrate that a backup is authentic, complete, and restorable, all without exposing your encryption keys or decrypting the data. Your auditor can verify the proof independently. Your keys stay on your machine.

$ devsafe audit --format soc2 --output evidence/
✓ generated 14 backup integrity proofs
✓ chain verification: all sequences intact
✓ evidence pack written to evidence/

GDPR

The General Data Protection Regulation requires that organizations know where personal data is stored, who processes it, and how it is protected. DevSafe simplifies all three questions.

Data residency

Your backups go wherever you point them. If you configure an S3 bucket in eu-west-1, your data stays in the EU. If you use Cloudflare R2 with a European storage hint, your data stays in European data centers. DevSafe does not choose your storage region. You do.

No data processing by HXA Labs

DevSafe is a local CLI tool. Your source code never leaves your machine in unencrypted form. The encrypted git bundles go directly from your machine to your own storage provider. HXA Labs does not operate any servers that receive, process, or store your code. This means HXA Labs is not a data processor under GDPR for your repository content.

Key residency

Encryption keys are generated on your machine using HKDF-SHA256 key derivation. They are stored locally (or in your organization's key management system). Keys never leave your machine during normal operation. There is no key escrow and no recovery service hosted by HXA Labs.

HIPAA

Healthcare organizations that handle protected health information (PHI) must comply with HIPAA's Security Rule. If your source code repositories contain PHI (configuration files with patient identifiers, test fixtures with health records, etc.), DevSafe's architecture supports HIPAA compliance.

Encryption requirements

Business Associate Agreement

HXA Labs offers a Business Associate Agreement (BAA) for healthcare teams on the Enterprise plan. Because DevSafe's architecture keeps PHI in customer-controlled storage and never transmits unencrypted data to HXA infrastructure, the BAA scope is narrow. Contact sales@devsafe.com for details.

Export controls

DevSafe uses AES-256, which is classified as EAR99 under U.S. Export Administration Regulations. EAR99 items do not require an export license for most destinations. AES-256 is a widely available, standard encryption algorithm with no special export restrictions for commercial software.

DevSafe does not implement any custom or proprietary cryptographic algorithms. All cryptographic operations use well-known primitives (AES-256-GCM, HKDF-SHA256) from vetted libraries.

If your organization operates under specific export control requirements (ITAR, sanctions programs), consult your export compliance counsel before deploying any encryption software.

Evidence generation

Compliance is only useful if you can prove it. DevSafe includes two commands purpose-built for generating audit evidence.

devsafe audit

The devsafe audit command produces a complete record of backup operations for a given time range. It verifies the tamper-evident chain, confirms that every backup in the sequence is present and unmodified, and outputs the results in a structured format.

$ devsafe audit --from "2026-01-01" --to "2026-06-30" --format json
{
  "period": "2026-01-01 to 2026-06-30",
  "repositories": 14,
  "total_backups": 4291,
  "chain_intact": true,
  "gaps": 0,
  "verification_failures": 0
}

devsafe export-proof

The devsafe export-proof command generates a standalone proof file that a third party (your auditor, your compliance team) can verify independently. The proof confirms that a specific backup exists, that it has not been tampered with, and that it is restorable. The proof does not contain your encryption key or any decrypted data.

$ devsafe export-proof --repo api-server --output proof-q2-2026.json
✓ proof covers 612 backups (Jan 1 to Jun 30)
✓ Merkle root: a3f7c9...d12e
✓ written to proof-q2-2026.json

# your auditor verifies with:
$ devsafe verify-proof proof-q2-2026.json
✓ proof valid, chain intact, 612/612 backups verified

What the evidence proves

• Completeness. Every backup in the sequence is accounted for. No gaps in the chain.
• Integrity. No backup has been modified after creation. The tamper-evident chain catches any alteration.
• Restorability. Each backup can be decrypted and restored to a valid git repository. This is verified cryptographically, not by actually restoring every backup.
• Temporal ordering. Backups are sequenced. The chain proves that backup N existed before backup N+1.

Framework summary