ciso

Use when checking how audit-ready the tracked certification data actually is -- controls claimed as met with no evidence behind them, assessments that have gone stale, thin or evasive justifications, controls never assessed at all. Also produces ISO 27001's draft Statement of Applicability. Reports on data already recorded; use ciso:interview to record or change it.

Use when attaching a merged pull request, commit, CI/CD run, scan result, or document to a tracked security control as durable proof that it is implemented -- typically right after a PR merges or a pipeline finishes. Records the artifact against the control; it does not change the control's assessed status.

Use when compiling or refreshing the public, non-authoritative topic-level HITRUST e1/i1 control structure files shipped in the ciso plugin -- e.g. after a new HITRUST CSF framework version ships, or to close a coverage gap in an existing compile. r2's full structure is out of scope for this skill until its own dedicated pass (its real scope is 2000+ entries, an order of magnitude beyond e1/i1).

Use when importing an organization's own licensed HITRUST MyCSF requirements export (an .xlsx file) into ciso tracking, replacing the shipped non-authoritative topic-level control set with the real per-statement requirements. Only HITRUST has an importable publisher export.

Use when setting up ciso security-certification tracking in a project for the first time, or when its state file or dashboard is missing and needs to be scaffolded.

Use when running the control-by-control (or criterion-by-criterion, or requirement-by-requirement) assessment that records whether each one is met, in progress, a gap, or not applicable, together with the justification behind that answer. This is the main assessment conversation; use ciso:audit instead to check readiness of assessments already recorded.

Use when adding a security certification -- HITRUST CSF, SOC 2, ISO/IEC 27001, or CMMC -- to ciso tracking for the first time, loading its control set into docs/ciso/state.json so the controls can then be assessed. This is the setup step that comes before any assessment; use ciso:interview to actually assess the controls it registers.

Use when reviewing a pull request, branch, or diff for security-compliance impact before it merges -- which tracked controls the change supports, which it might regress, and which open gaps it leaves untouched. Reads code and tracking data; writes nothing. Use ciso:evidence afterwards to record what the change actually proves.

Use when researching budget-appropriate vendor, SaaS, or open-source solutions for controls that the assessment recorded as gaps or in progress -- what to buy or adopt to close them. Runs the research in the background without blocking other work.

Use when defining the boundaries of a SOC 2 engagement before the assessment starts -- Type I versus Type II, which Trust Services Categories are in scope, the observation period, subservice organizations and how they are treated, the system description. Only SOC 2 has a scope step; HITRUST, ISO 27001 and CMMC do not.

Use when pushing outstanding HITRUST control gaps from ciso's docs/ciso/state.json into JIRA or Linear as trackable tickets, or when re-running that sync to pick up newly-resolved or newly-gapped controls.

Use when the plugin ships a newer version of a certification's control set than a project has recorded, and the existing assessment data needs reconciling against it -- controls added, removed, or changed between framework versions. Also use when a version-mismatch warning sends you here.