> For the complete documentation index, see [llms.txt](https://intuitem.gitbook.io/ciso-assistant/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://intuitem.gitbook.io/ciso-assistant/product-docs/introduction/philosophy.md). # Philosophy CISO Assistant is built around a small set of design principles. A lot of object boundaries, naming choices, and workflow shapes only make sense once you have these in mind. ## Applied controls at the centre The **applied control** is the unifying object in CISO Assistant. Everything the organisation *does* to manage risk and prove compliance is captured as an applied control — a technical safeguard, an organisational process, a documented policy, a tested recovery plan. Once that's in place, the rest of the platform connects to it: * An **audit** assesses requirements; each requirement assessment links to the applied controls that satisfy it. * A **risk scenario** lowers its current and residual levels by attaching the applied controls in place and planned. * A **task** records that an applied control was actually exercised on a given date and produces the evidence to prove it. * **Evidence** lives on an applied control — and through it, substantiates every requirement and scenario the control supports. * An **incident** response invokes applied controls; a **vulnerability** is mitigated by them; a **policy** *is* one. Authoring an applied control once and reusing it across all the places it applies — instead of redoing the same work per audit, per risk study, per framework — is the productivity gain that justifies the whole architecture. ## Decoupling principle The corollary of putting applied controls at the centre is that everything around them must be decoupled, so that one applied control can serve many consumers without being rewritten for each: * **Security controls** are decoupled from **compliance requirements** — a single applied control can satisfy many requirements across many frameworks. * **Risk assessments** are decoupled from **frameworks** — the same risk scenario can inform multiple compliance audits. * **Assets** are decoupled from **threat scenarios** — assets exist independently of any specific risk study and can be reused across them. The payoff is reuse, end-to-end. One applied control answers many requirements. One assessment covers many frameworks. One asset participates in many scenarios. One evidence file substantiates everything the underlying control supports. {% embed url="" %} Decoupling concept — full screen is recommended for a better experience. {% endembed %} --- # 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://intuitem.gitbook.io/ciso-assistant/product-docs/introduction/philosophy.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.