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.
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:- All information systems owned or operated by Denialbase — production, staging, development, CI/CD, business-operations tools.
- All personnel — employees, contractors, consultants, interns — regardless of role or location.
- All information created, received, processed, stored, or transmitted by Denialbase, at every classification level (Data classification).
- All subprocessors that may handle Denialbase customer data — see Subprocessors.
Information security objectives (ISO 27001 clause 6.2)
- Zero PHI breaches per 12-month period.
- ≤ 4 hour MTTR for Sev-1 incidents.
- 100% quarterly access review completion.
- ≥ 95% annual security awareness training completion.
- 0 sustained critical risks in the Risk register.
- Audit-ready for SOC 2 Type I by Q4 2026, ISO 27001 stage-1 by Q1 2027.
Core principles
Confidentiality
Information is accessible only to those authorized. PHI is accessed only on a minimum-necessary basis, via authenticated channels, with an audit trail.
Integrity
Information is protected from unauthorized modification. Audit logs are write-once. Changes to code, infrastructure, and policy flow through reviewed, logged pipelines.
Availability
Customers can access and use their data when they need it. Production services target 99.9% availability with documented DR procedures.
Accountability
Every privileged action is attributable to a named actor. No shared credentials. No anonymous production access.
Least privilege
Access is granted at the minimum level required. Role-based defaults, just-in-time elevation, automatic revocation on offboarding.
Defense in depth
Multiple independent controls protect every asset. No single control failure should expose customer data.
Transparency
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.
Continual improvement
The ISMS evolves. Incidents, audits, and reviews produce tracked improvements. We expect to be better in 12 months than today.
Commitments
Denialbase commits to:- 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.
- Meet contractual obligations — including Business Associate Agreements with every covered-entity customer and every subprocessor that may touch PHI.
- Protect PHI through encryption at rest and in transit, with customer-managed encryption keys where supported.
- Authenticate strongly — multi-factor for all PHI-accessing accounts, passkeys recommended.
- Audit comprehensively — every PHI access, modification, and export is logged with 7-year retention.
- Separate duties — segregation of responsibilities prevents any single person from compromising production unilaterally.
- Respond to incidents promptly — detection, triage, containment, notification, recovery, and learning all follow a documented path.
- Train the workforce — everyone receives security awareness training on hire and annually.
- Review and test controls — internal audit annually, penetration testing annually (once contracted), DR drills annually.
- Provide for continual improvement — findings from incidents, audits, and reviews become tracked corrective actions.
Governance structure
CEO — ultimate accountability
CEO — ultimate accountability
Approves this policy. Accountable for the ISMS overall and for resourcing it. Chairs the annual strategic management review.
Security Officer — operational owner
Security Officer — operational owner
Owns the ISP, the Risk register, the Statement of Applicability, the Internal audit program, and security incident response. Approves exceptions in writing. Reports at the quarterly management review.
Privacy Officer
Privacy Officer
Accountable for HIPAA Privacy Rule obligations, data subject rights, breach notification decisions. Coordinates with Security Officer on privacy-security overlap.
CTO — technical implementation
CTO — technical implementation
Owner of technical controls — infrastructure, application, CI/CD, encryption, logging, DR. Participates in management reviews.
Engineering team
Engineering team
Implements controls in code and infrastructure. Reviews each other’s security-sensitive changes. Follows Change management.
Head of People / HR (where applicable)
Head of People / HR (where applicable)
Operationally responsible for HR security — screening, onboarding, offboarding, disciplinary actions.
Every workforce member
Every workforce member
Required to follow this policy, the AUP, 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 |
| Access Control Policy | Access control |
| Cryptography Policy | Cryptography |
| Data Classification Policy | Data classification |
| Change Management Policy | Change management policy |
| Incident Response Plan | Incident response |
| Disaster Recovery Plan | Disaster recovery |
| Business Continuity Plan | Business continuity |
| Vendor / Supplier Management | Vendor management |
| HR Security | HR security |
| Risk Management (and register) | Risk register |
| Security Awareness Training | 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.
- Exceptions are reviewed at every 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 and AUP enforcement.
- Termination of employment or contractor relationship.
- Legal action, where applicable.
- Notification of regulatory authorities, where required by law.
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. |