> For the complete documentation index, see [llms.txt](https://docs.owkin.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.owkin.com/governance-and-security/security-architecture/security-measures.md). # Security measures We adhere to a 15-point Security Principle Framework that prioritizes proactive design, strict access controls, and resilience. The strategy is built on the philosophy that security is everyone's responsibility, compliance is merely a baseline, and systems must be designed assuming that breaches can occur (Zero Trust). #### Pillar 1: Secure Architecture & Infrastructure Focus: Building a hardened foundation that minimizes the blast radius of any potential attack. * Security by Design & Defense in Depth: We do not rely on a single control. Security is integrated during the architecture phase to prevent costly rework, using layered defenses (e.g., App auth + Network ACLs). * Zero Trust & Immutable Infrastructure: We trust nothing by default. Every request is verified regardless of origin. Infrastructure is deployed via code (IaC) rather than manual patches to prevent configuration drift. * Resilience: We design systems to degrade gracefully, assuming failure is inevitable, and prioritize fast recovery (MTTR). #### Pillar 2: Identity & Access Management Focus: Ensuring only the right people and services have access to the right resources. * Least Privilege: Access is restricted to the absolute minimum required for a role. * Strong IAM: We enforce centralized identity management and Multi-Factor Authentication (MFA) to protect against credential theft. #### Pillar 3: The Secure Development Lifecycle (SDLC) Focus: Automating security to catch vulnerabilities before they reach production. * Shift Left: Security testing (static analysis) happens early in the CI/CD pipeline, not just before deployment. * Secure Defaults: Systems launch with the most secure settings enabled automatically (e.g., encryption on by default). * Supply Chain Security: We actively scan and validate third-party dependencies and libraries to prevent upstream attacks. #### Pillar 4: Visibility & Data Protection Focus: Knowing what we have, protecting it, and watching it closely. * Data Classification: Sensitive data (PII/PHI) is identified, tagged, and encrypted according to its risk level. * Auditability & Monitoring: We implement comprehensive logging and real-time behavioral analytics to detect anomalies immediately. * Incident Readiness: We don't just watch; we practice. Tabletop exercises ensure we are ready to respond to incidents effectively. #### Pillar 5: Culture & Compliance Focus: Making security a human norm rather than just a technical requirement. * Shared Responsibility: Security is an organizational norm; engineers are trained to own the security of their code. * Compliance as Baseline: We view regulatory requirements as the "floor," not the "ceiling," effectively going beyond what is legally required to ensure true safety. For more information please visit our[ Trust Centre on Vanta](https://app.vanta.com/owkin/trust/qq8guymgbci1jnk49kjbc) Email: --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.owkin.com/governance-and-security/security-architecture/security-measures.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.