> 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/concepts/governance/findings-assessments.md). # Findings binders A **findings binder** collects the issues raised by one review and drives their remediation through to closure. The issues themselves are **findings**, and they can come from a CISO Assistant audit, a penetration test, a technical posture scan, an external assessor's report, a responsible disclosure, or someone simply noticing something. It's the place where the action plan meets reality: each non-compliance, observation, or recommendation gets an owner, a due date, and a status, and is followed all the way to closed. {% hint style="info" %} Findings binders are the model formerly surfaced as **Follow-up**. The object, its API path (`findings-assessments`), and its data are unchanged — only the label moved. {% endhint %} ## Mental model ```mermaid graph TD D[Domain] -->|scopes| FB[Findings binder] P[Perimeter] -.->|narrows| FB A[Audit] -.->|reviewed by| FB FB -->|comprises| F[Findings] F -.->|remediated by| AC[Applied controls] F -.->|evidenced by| E[Evidences] ``` A findings binder is an **assessment**, in the same family as audits, risk assessments, and business impact analyses: it lives in a **domain**, optionally narrows to a **perimeter**, carries authors, reviewers, a status and a version, and can be locked. Inside it sit the individual **findings**, each remediated by one or more **applied controls** and backed by **evidences**. A binder can point back at the **audit** whose findings it captures, which is what the [findings-from-requirements](#raising-a-finding-from-a-requirement) flow uses. | User-facing | Internal | Notes | | --------------- | ---------------------- | ------------------------------------------- | | Findings binder | `FindingsAssessment` | Subclass of the shared `Assessment` base | | Finding | `Finding` | Can stand alone — a binder is optional | | Domain | `Folder` | Required; drives IAM scoping | | Perimeter | `Perimeter` | Optional | | Audit | `ComplianceAssessment` | Optional back-link, set by the findings tab | ## What a binder records Beyond the assessment basics (name, version, status, authors, reviewers, domain, perimeter): * **Category** — Pentest, Threat hunting, Red teaming, Audit, Self-identified, Posture follow-up, or Responsible disclosure. This is what lets dashboards separate "what the pentester found" from "what the auditor found". * **Audit** — the audit whose findings this binder captures, when there is one. * **Reference ID** and **Reference link** — the assessor's own identifier and a URL to the report, ticket, or external tracker. * **Reported at** and **Start date** — when the review reported, and when it began. * **Objectives** — what this campaign of findings sets out to achieve. * **Budget** and **Expenses** — what the engagement was allotted, and what it has consumed so far. * **Evidences** — the report itself, the scope letter, the rules of engagement. Locking a binder freezes it: its findings can no longer be modified, which is how a signed-off pentest report stays the record of what was found. ## Findings A finding carries a **severity** (from informational to critical), a **status** (undefined → identified → confirmed → assigned → in progress → mitigated → resolved → closed, plus dismissed and deprecated), an optional **priority** (P1–P4), an **owner**, and an **ETA** / **due date**. Two text fields separate the observation from the answer to it: * **Observation** — what was found. * **Recommendation** — what should be done to close it. A finding can also point at the things it concerns: an **asset**, a **requirement** and the **requirement assessment** it was raised from, **threats**, **vulnerabilities**, **reference controls**, and the **applied controls** that remediate it. The applied-control link is many-to-many: one control can close several findings, and one finding can need several controls. ### Standalone findings A finding does not have to belong to a binder. Leave the binder empty and it stands on its own — appropriate for something spotted in passing that doesn't warrant a whole engagement record. Standalone and bound findings appear together in the **Findings** list under Governance, so nothing is lost by not opening a binder. A bound finding takes its domain from its binder; detach it to move it elsewhere. ## Where findings come from The same model serves every source, which is what makes cross-source reporting possible — *all open critical findings due this quarter* is one question, not one per review type: * **Audits** — non-compliances raised while assessing requirements, especially with [extended results](/ciso-assistant/concepts/compliance/audits/extended-results.md) enabled. * **Technical postures** — failing checks routed into a binder with the *Posture follow-up* category. See [technical postures](/ciso-assistant/concepts/compliance/technical-postures.md). * **External assessments** — pentest reports, third-party security reviews, regulator inspections. These are typically bulk-loaded through the [data import wizard](/ciso-assistant/configuration/data-import.md), which has a dedicated findings-binder importer. * **Internal reviews and self-identified issues** — checks outside the formal audit cycle. * **Responsible disclosure** — issues reported from outside the organisation. ### Raising a finding from a requirement With the **findings\_from\_requirements** [feature flag](/ciso-assistant/configuration/settings/feature-flags.md) on, a requirement assessment gains a **Findings** tab. **Raise a finding** records the issue without leaving the requirement, and the picker binds an existing finding from any binder to the requirement. A finding is bound to one requirement assessment at a time: the picker skips findings bound elsewhere, and moving one is done from the finding. A locked binder keeps its findings where they are, and a locked audit refuses new ones. The first finding raised on an audit creates that audit's binder automatically — named after the audit, in the audit's domain and perimeter, with the *Audit* category — and every later finding on the same audit joins it. Creating it needs permission to add a findings binder in the audit's domain. If the audit already has binders, the oldest one is used. ## Related * [Audits](/ciso-assistant/concepts/compliance/audits.md) * [Applied controls](/ciso-assistant/concepts/operations/applied-controls.md) * [Technical postures](/ciso-assistant/concepts/compliance/technical-postures.md) * [Vocabulary → Findings binder](/ciso-assistant/introduction/vocabulary.md) --- # 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/concepts/governance/findings-assessments.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.