Skip to main content
Denialbase is HIPAA-compliant today. We are pursuing formal SOC 2 Type I and ISO 27001:2022 certifications. This page is our transparent, evidence-backed readiness tracker — it names what’s done, what’s partial, and what’s missing.

​
Readiness snapshot

Based on a structured review of our infrastructure-as-code, source code, CI/CD pipelines, and documentation as of April 2026.

Overall maturity

47 / 100 — Level 2 (Repeatable Technical Controls)Technical controls are well ahead of governance. Estimated 6–9 months to audit-readiness with focused governance and policy work.

Technical strength

78 / 100 — Technical Security 71 / 100 — Operations & MonitoringEncryption, auth, network, CI/CD security, secrets management — all in place.

Governance gap

12 / 100 — Governance & Policies 10 / 100 — Risk Management 18 / 100 — HR / Incident Response 22 / 100 — Supplier SecurityFormal policies, risk register, and BAA execution are the remediation focus.

​
SOC 2 criteria — estimated maturity

Percentages below estimate control maturity based on design, implementation, and repository-observable evidence. They are not audit scores.
Trust Service CriterionEstimated maturityStatus
Security (CC)58%Partial
Availability (A)55%Partial
Confidentiality (C)50%Partial
Processing Integrity (PI)45%Partial
Privacy (P)30%Not evidenced

​
What’s working today

  • Customer-managed encryption keys (CMEK) on Cloud SQL, GCS, Memorystore Redis, and Terraform state, with 90-day automatic key rotation.
  • Active Record column-level encryption for PHI on the User, InsuranceMember, InsuranceProfile, and OverturnableDenial models. Deterministic for queryable fields (names, member IDs); non-deterministic for the rest.
  • TLS 1.2+ in transit, enforced at the load balancer.
See Encryption for implementation detail.
  • Passwords (12-char minimum, complexity validator, zxcvbn), TOTP (RFC 6238), passkeys (WebAuthn), Google OAuth 2.1.
  • Account lockout after 5 failed attempts (1-hour auto-unlock).
  • 48 Pundit policy files enforce object-level authorization, globally gated by after_action :verify_authorized — every API action must authorize or explicitly skip.
  • Rack::Attack rate limiting on auth, 2FA, passkey, email, and token endpoints. Backed by Memorystore Redis for cross-instance consistency.
  • Google Cloud Armor WAF with the full OWASP Core Rule Set v3.3 (SQLi, XSS, RCE, LFI/RFI, scanner detection, protocol attacks).
  • Per-IP rate limiting at the load balancer (500–1000 req/min with 5-minute ban on breach).
  • Private VPC for Cloud SQL and Redis. Workload Identity Federation for CI/CD — no long-lived service account keys.
  • hipaa_audit_logs table records every PHI access, modification, export, and disclosure.
  • security_audit_logs records authentication events, account lockouts, 2FA changes, admin actions.
  • Retention: 7 years (exceeds HIPAA’s 6-year minimum).
See Audit logging.
  • Multi-stage GitHub Actions pipeline with blocking security gates: Brakeman (SAST), bundler-audit (dependency CVEs), Trivy (Terraform config scanning), license_finder (OSS license compliance).
  • 90% backend coverage and 80% frontend coverage required to merge.
  • All builds sign + attest to artifact registry via Workload Identity Federation.
See Change management.

​
What’s in progress or missing

We’re publishing this section because buyers deserve to see it before asking. Every item below is tracked in our internal risk register with an owner and target date.
The items in this section are not yet ready for a formal SOC 2 or ISO 27001 audit. We expect to close the highest-impact gaps in the next 6–9 months.

​
Critical gaps

Status: Our BAA tracker shows “Not yet signed” for GCP, Anthropic, Sentry, and Amazon SES as of April 2026. We are actively working on executing these.Why it matters: HIPAA requires a signed BAA with every subprocessor that handles PHI. Until these are executed, we rely on each vendor’s default data handling terms and our technical PHI-minimization controls.Mitigations today:
  • PHI is column-level-encrypted before leaving our database.
  • Anthropic calls use PHI-scrubbed prompts; raw PHI is never sent to the LLM.
  • Sentry has PII scrubbing rules configured to redact known PHI field names.
  • Amazon SES is used only for transactional email — no PHI in email bodies.
Target: All four BAAs executed by Q3 2026.See BAAs and Subprocessors.
Status: The Active Record column-encryption migration is incomplete. Some PHI columns in the OverturnableDenial and ProviderPatientLink tables (e.g., patient_name, patient_dob, patient_email, patient_phone) are declared as encrypts on the model but stored as plaintext strings in the database schema — indicating the backfill migration was started but not completed.Mitigations today:
  • All data is encrypted at rest via CMEK at the Cloud SQL level (AES-256 with customer-managed keys).
  • Access to the database is restricted to private VPC only; no public ingress.
  • All access is audit-logged.
Target: Column-level encryption migration completed and verified by Q2 2026.
Status: A disaster recovery plan exists, but a formal standalone Incident Response Plan (IRP) with named responders, escalation paths, and tested runbook is still in draft. Contact placeholders remain in the draft.Target: IRP published, tabletop-tested, and linked from Incident Response by Q2 2026.
Status: DR procedures are documented (backups, PITR, restore runbook). Formal test exercises (backup verification, PITR test, full DR drill, tabletop) are on the schedule but have not been executed yet.Mitigations today:
  • Cloud SQL point-in-time recovery (PITR) is enabled.
  • Automated daily backups with 30-day retention.
  • Backups stored in a separate CMEK-encrypted GCS bucket.
Target: First full DR drill executed and results documented by Q2 2026.See Disaster Recovery.

​
High-priority gaps

Status (April 2026 update): Remediated. The full policy stack is published in this Trust Center — Information Security Policy v1.0, Acceptable Use Policy v1.0, Risk Register v1.0, plus Access Control, Cryptography, Data Classification, Change Management, HR Security, Security Awareness, Vendor Management, and Statement of Applicability. CEO sign-off pending on ISP + AUP.Remaining: CEO formal approval + first annual review cycle.
Status: No third-party penetration test has been commissioned yet. We run Brakeman SAST and bundler-audit on every PR, and Trivy against our Terraform, but these don’t substitute for a dynamic, adversarial test.Target: Engage a CREST-accredited or equivalent pentest firm by Q3 2026; publish a sanitized executive summary at Penetration testing.
Status (April 2026 update): Remediated. jwt.rotation_secret is wired to DEVISE_JWT_SECRET_KEY_PREVIOUS — during a rotation window, tokens signed with either the current or previous key verify. Specs cover both paths. See config/initializers/devise_jwt.rb and SECRET_ROTATION.md for the 8-step rotation runbook.Mitigations in place:
  • JWTs are httpOnly + Secure cookies; not accessible to JavaScript.
  • Session expiry is bounded — cookie TTL now matches JWT payload TTL (4 hours).
  • Keys live in GCP Secret Manager with access audit logs.
Status (April 2026 update): Remediated for staging. iam.disableServiceAccountKeyCreation and iam.disableServiceAccountKeyUpload are both enforce: true on denialbase-dev (staging). New SA key creation and upload are now blocked at the project level; existing keys are unaffected.Remaining: Promote to production after a 1–2 week staging soak (target Q2 2026).

​
How we’re tracking this

Every item in this page is owned by a named responder in our internal risk register and reviewed monthly. This public page is updated at least quarterly or whenever a material gap is closed.
Want a deeper look? Enterprise customers can request our full SOC 2 Type I readiness report (signed mutual NDA) at security@denialbase.com.

​
Questions

General inquiries

security@denialbase.com

Request a BAA

See the BAA page for the request process.