Skip to main content
This policy defines four classifications and the handling rules for each. Every piece of data at Denialbase falls into one of the four. The higher the classification, the stricter the handling.
Owner: Security Officer · Policy version: 0.9 (draft) · Review cadence: Annual

​
Classifications

Restricted — PHI

Protected Health Information subject to HIPAA. Patient identifiers, clinical information, claim/denial data tied to a person.

Confidential

Customer data that isn’t PHI (practice metadata, settings, billing), Denialbase source code, secrets, internal financial data.

Internal

Denialbase workforce communications, plans, non-PHI dashboards, non-sensitive documentation.

Public

Marketing content, public docs, this Trust Center, support articles.

​
Full classification table

ClassificationExamplesWho can accessDefault labeling
Restricted — PHIPatient name, DOB, MRN, diagnosis codes, denial/appeal content tied to a patient, EOBs, medical recordsCustomer’s own org; Denialbase support with ticket+audit; production runtime[PHI] or red banner on internal dashboards
ConfidentialCustomer settings, practice names, billing data, Denialbase source code, encryption keys, BAAs, subprocessor contracts, financial dataCustomer’s own org; role-scoped Denialbase staff; engineering for code[Confidential] in docs, private in code
InternalNon-PHI dashboards, internal planning docs, workforce communications, internal retrospectivesAll Denialbase workforce[Internal] in docs
PublicMarketing, public docs, Trust Center, status page, job postingsAnyoneNo label

​
Handling rules

​
Restricted — PHI

  • Production database (Cloud SQL) with CMEK at rest + Active Record column-level encryption.
  • Document storage in CMEK-encrypted GCS buckets with public_access_prevention = enforced.
  • Never stored in dev/test environments.
  • Never stored on workstations, personal accounts, or third-party tools not on our subprocessor list.
  • TLS 1.2+ mandatory.
  • Private VPC for internal Denialbase-to-GCP traffic.
  • PHI scrubbed before egress to LLM (Anthropic) and error monitoring (Sentry).
  • Never in email bodies. Never in SMS.
  • Role-based (Pundit) with customer-scoped tenancy isolation.
  • Denialbase support access requires: ticket + customer authorization + audit log.
  • Privileged production access is just-in-time, time-limited, audit-logged.
  • Minimum-necessary principle per HIPAA §164.514.
  • With customers (covered entities): in-app only, via authenticated channels.
  • With subprocessors: only those on the BAA-in-place list; minimum necessary; contractually required deletion.
  • With regulators: per HIPAA breach notification or lawful process, documented in legal record.
  • Account/practice deletion triggers User#permanently_delete! or equivalent: encrypted records destroyed, audit entries retained per HIPAA.
  • Backups age out per the DR retention policy.
  • Backup media (cloud) — destruction inherited from GCP media handling.
  • Every access, mutation, export, and disclosure is recorded in hipaa_audit_logs with 7-year retention.

​
Confidential

  • Source code in GitHub with MFA enforcement + SSO.
  • Secrets in GCP Secret Manager — never in source, env files, or CI variables.
  • Customer non-PHI data in the same database + GCS buckets (same encryption at rest).
  • Business docs in Google Workspace with access restricted to relevant roles.
  • TLS in transit.
  • Secrets accessed only by service accounts via IAM bindings.
  • Role-scoped. Source code reachable by engineering team; business docs by relevant functions.
  • Secrets accessible to production runtime service accounts only.
  • Customer data: to the customer themselves; to subprocessors only if listed in the Subprocessors page.
  • Source code: never; Denialbase source is proprietary.
  • Business docs: case-by-case under NDA.
  • Repos retained for business/legal purposes; individual commits not deletable.
  • Customer non-PHI data purged alongside PHI on account deletion.

​
Internal

  • Stored in Google Workspace, Slack, Notion, or equivalent internal tools.
  • Accessible to the Denialbase workforce by default.
  • Not shared externally without approval.
  • No PHI or customer-identifiable content (which would promote to Confidential or Restricted).

​
Public

  • Accessible to anyone.
  • Subject to brand and legal review before publication.
  • Changes tracked in the repo/CMS so we can audit what we said and when.

​
Labeling

Documents containing Restricted or Confidential data carry a visible label in the title or header (e.g. [Confidential — Subprocessor Contract]).
Secrets and PHI-adjacent code paths are commented with # PHI or # confidential near the relevant model / controller method. The PhiEncryption concern labels encrypted models at declaration time.
Any screenshot shared externally (marketing, sales, support) uses seed/demo data — never real PHI.
PHI is either scrubbed at log-write time or redacted before ingestion by Sentry / external systems.

​
Derived data

When data of one classification is derived from another, the derivative inherits the higher classification:
  • Aggregated counts from PHI → may downgrade to Internal if de-identified under HIPAA §164.514 (Expert Determination or Safe Harbor).
  • Patient-anonymized case studies → Internal if de-identified; Public only after signed author review and legal approval.
  • Denialbase-internal metrics computed over customer data → Internal (no direct PHI).

​
Exceptions

Exceptions require written approval from the Security Officer and are tracked with a 6-month expiry and review requirement.