> ## Documentation Index
> Fetch the complete documentation index at: https://trust.denialbase.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Information Security Policy
> The top-level policy governing all security controls at Denialbase, aligned with ISO 27001 clause 5.2 and SOC 2 CC1.
This policy anchors the Denialbase Information Security Management System (ISMS). Every supporting policy, procedure, and control derives authority from this document. Every workforce member reads and acknowledges it on hire and annually.
**Owner**: Security Officer · **Approved by**: CEO · **Policy version**: 1.0 · **Effective**: April 2026 · **Next review**: April 2027
## Purpose
This policy establishes Denialbase's commitment to protecting the confidentiality, integrity, and availability of information assets — especially Protected Health Information (PHI) — entrusted to us by our covered-entity customers.
It supports the broader objectives of:
* Complying with HIPAA (Privacy, Security, and Breach Notification rules).
* Pursuing and maintaining SOC 2 Type II and ISO 27001:2022 certifications.
* Meeting customer contractual obligations.
* Earning and retaining the trust of healthcare providers and their patients.
## Scope
This policy applies to:
1. **All information systems** owned or operated by Denialbase — production, staging, development, CI/CD, business-operations tools.
2. **All personnel** — employees, contractors, consultants, interns — regardless of role or location.
3. **All information** created, received, processed, stored, or transmitted by Denialbase, at every classification level ([Data classification](/trust/data-classification-policy)).
4. **All subprocessors** that may handle Denialbase customer data — see [Subprocessors](/trust/subprocessors).
## Information security objectives (ISO 27001 clause 6.2)
1. **Zero PHI breaches** per 12-month period.
2. **≤ 4 hour MTTR** for Sev-1 incidents.
3. **100%** quarterly access review completion.
4. **≥ 95%** annual security awareness training completion.
5. **0 sustained critical risks** in the [Risk register](/trust/risk-register).
6. **Audit-ready** for SOC 2 Type I by Q4 2026, ISO 27001 stage-1 by Q1 2027.
Progress against these objectives is reviewed at each [Management review](/trust/management-review).
## Core principles
Information is accessible only to those authorized. PHI is accessed only on a minimum-necessary basis, via authenticated channels, with an audit trail.
Information is protected from unauthorized modification. Audit logs are write-once. Changes to code, infrastructure, and policy flow through reviewed, logged pipelines.
Customers can access and use their data when they need it. Production services target 99.9% availability with documented DR procedures.
Every privileged action is attributable to a named actor. No shared credentials. No anonymous production access.
Access is granted at the minimum level required. Role-based defaults, just-in-time elevation, automatic revocation on offboarding.
Multiple independent controls protect every asset. No single control failure should expose customer data.
Customers know what we do, what we don't do, what we've verified, and what we haven't. Gaps are tracked on this Trust Center, not hidden.
The ISMS evolves. Incidents, audits, and reviews produce tracked improvements. We expect to be better in 12 months than today.
## Commitments
Denialbase commits to:
1. **Comply with applicable laws and regulations** — HIPAA, state breach notification laws, ERISA (where applicable), ACA (where applicable), GDPR (for non-US data if we ever expand), and others as adopted.
2. **Meet contractual obligations** — including Business Associate Agreements with every covered-entity customer and every subprocessor that may touch PHI.
3. **Protect PHI through encryption** at rest and in transit, with customer-managed encryption keys where supported.
4. **Authenticate strongly** — multi-factor for all PHI-accessing accounts, passkeys recommended.
5. **Audit comprehensively** — every PHI access, modification, and export is logged with 7-year retention.
6. **Separate duties** — segregation of responsibilities prevents any single person from compromising production unilaterally.
7. **Respond to incidents promptly** — detection, triage, containment, notification, recovery, and learning all follow a documented path.
8. **Train the workforce** — everyone receives security awareness training on hire and annually.
9. **Review and test controls** — internal audit annually, penetration testing annually (once contracted), DR drills annually.
10. **Provide for continual improvement** — findings from incidents, audits, and reviews become tracked corrective actions.
## Governance structure
Approves this policy. Accountable for the ISMS overall and for resourcing it. Chairs the annual strategic management review.
Owns the ISP, the [Risk register](/trust/risk-register), the [Statement of Applicability](/trust/statement-of-applicability), the [Internal audit](/trust/internal-audit) program, and security incident response. Approves exceptions in writing. Reports at the quarterly management review.
Accountable for HIPAA Privacy Rule obligations, data subject rights, breach notification decisions. Coordinates with Security Officer on privacy-security overlap.
Owner of technical controls — infrastructure, application, CI/CD, encryption, logging, DR. Participates in management reviews.
Implements controls in code and infrastructure. Reviews each other's security-sensitive changes. Follows [Change management](/trust/change-management).
Operationally responsible for [HR security](/trust/hr-security) — screening, onboarding, offboarding, disciplinary actions.
Required to follow this policy, the [AUP](/trust/acceptable-use-policy), and applicable procedures. Required to report suspected incidents immediately. Required to complete training.
## Supporting policies
This ISP is supported by — and takes precedence over — the following subsidiary policies:
| Policy | Link |
| ------------------------------ | ----------------------------------------------------------- |
| Acceptable Use Policy | [AUP](/trust/acceptable-use-policy) |
| Access Control Policy | [Access control](/trust/access-control-policy) |
| Cryptography Policy | [Cryptography](/trust/cryptography-policy) |
| Data Classification Policy | [Data classification](/trust/data-classification-policy) |
| Change Management Policy | [Change management policy](/trust/change-management-policy) |
| Incident Response Plan | [Incident response](/trust/incident-response) |
| Disaster Recovery Plan | [Disaster recovery](/trust/disaster-recovery) |
| Business Continuity Plan | [Business continuity](/trust/business-continuity) |
| Vendor / Supplier Management | [Vendor management](/trust/vendor-management) |
| HR Security | [HR security](/trust/hr-security) |
| Risk Management (and register) | [Risk register](/trust/risk-register) |
| Security Awareness Training | [Security awareness](/trust/security-awareness) |
## Exceptions
* Any deviation from this policy or its subsidiary policies requires **written approval from the Security Officer**.
* Exceptions must include: business justification, risk acceptance owner, compensating controls, expiry date (maximum 12 months).
* Exceptions are tracked in the [Risk register](/trust/risk-register).
* Exceptions are reviewed at every [Management review](/trust/management-review).
## Consequences of non-compliance
Non-compliance with this policy may result in:
* Retraining (first-time minor issues).
* Disciplinary action per [HR security — discipline](/trust/hr-security#discipline-and-sanctions-annex-a-6-4) and [AUP enforcement](/trust/acceptable-use-policy#enforcement).
* Termination of employment or contractor relationship.
* Legal action, where applicable.
* Notification of regulatory authorities, where required by law.
Non-compliance may also trigger reassessment of subprocessor or customer relationships as appropriate.
## Review and revision
* **Annual** — full review by the Security Officer and approval by CEO.
* **Ad-hoc** — triggered by material changes: new regulation, significant incident, architectural change, new customer segment, new subprocessor category.
* **Version control** — every published version is archived in this repo's git history; a changelog at the bottom of this page records material revisions.
## Distribution
* **Internal**: linked from the onboarding checklist, 1Password policy vault, and annual training.
* **External**: this page is public. Sensitive supporting procedures (specific response runbooks with contact names, SoA with evidence paths) are available under NDA.
## Changelog
| Version | Date | Author | Material changes |
| ------- | ------- | ---------------- | ----------------------------------------------------------------------------------------------------- |
| 0.1 | 2026-04 | Security Officer | Initial public draft (superseded) |
| 1.0 | 2026-04 | Security Officer | First formally-approved version; expanded objectives, governance, exception process. Approved by CEO. |