Security & Auditing Skills

Assemble the quarterly security board pack or audit-committee pack from the section objects the other skills produce, and output it as a print-ready document and an editable PowerPoint deck. Reads each producer's .board.json against the versioned section contract, orders the sections for the audience, consolidates every section's decisions into one list the board actually votes on, reads each producer's own headline figures, and records on a provenance page what was missing. Owns no data and computes nothing: every fact comes from a producer's store and every sentence from ciso-board-translation, so a slot with no translation renders a visible placeholder rather than an invented line. Use when asked to build or assemble the board pack, put together the quarterly security deck or the audit-committee pack, produce the board deliverable for the quarter, or turn the registers and the profile into one narrative. NOT for a single section — translating one metric, running a risk review, or writing one board sentence belongs to the skill that owns it.

Translates raw security facts—a single metric, a specific risk, or a quarter of program work—into board-ready language a director will act on, backed by sourced regulatory receipts that carry their own honest limits. Use this whenever security content is going to a board, audit committee, or senior leadership: translate a metric or number for the board, "make this board-ready", build a board deck or report, an executive summary of security posture, "what do I tell the board", answering "are we secure?", a quarter-over-quarter security narrative, justifying a security budget to leadership, or framing a risk acceptance for the board. Other skills (for example risk-register) should invoke this for any board-facing security output. Every translation names the specific exposure, states the business consequence, shows the trend, and ends on a decision the board can make. NOT for general copywriting, security policy or procedure writing, or personal/career communications.

Maintain a defensible register of accepted residual risks and control exceptions that persists in a local file, so an auditor, a regulator or a board can be shown what the organisation knowingly accepted, on what basis, who approved it, and whether that reasoning is still valid. Records two object types with one lifecycle — acceptances and exceptions with their compensating controls — and refuses any record missing an approver, a justification or a re-validation date. Re-validation is recorded as an act with a rationale, never a timer reset. Derives current, due, overdue and expired status from the dates, exports the active inventory as the CSV or JSON evidence artifact a DORA or NYDFS reviewer asks for, and produces a board section whose language comes from ciso-board-translation. Use when asked to log or approve an exception or waiver, record a risk acceptance with its approver and expiry, run a re-validation review, list what is overdue for re-validation, or produce the risk-acceptance inventory. Accepted risks already in a risk register are fed in one-way with that skill's export-acceptances; this skill is the system of record for the lifecycle, and the register does not duplicate it.

Structure and record a cybersecurity incident materiality determination, and run the disclosure clocks that follow from it. Walks the six factors the judgment turns on — financial impact, operational disruption, data affected, regulatory and contractual triggers, reputational effects, and whether related incidents must be assessed as one series — recording each with its reasoning, the person and the date, and refusing an assessment that has no rationale. Never emits a verdict: no scale, no score, no threshold, because materiality is a legal judgment made with counsel and a generated number would be discoverable alongside the determination it disagreed with. Computes the SEC Item 1.05 window as four business days from the determination — not from discovery, so an incident still under assessment has no window open — and the DORA initial, intermediate and final report windows in clock hours. Keeps every determination as an appended record, so the "what did we know and when did we decide" sequence survives. Use when asked whether an incident is material, whether it has to be disclosed, when the 8-K clock starts or how much of it is left, to record a determination or a disclosure decision, to track DORA reporting windows, or to draft an audit-committee incident update. Not for incident-response runbooks, triage, containment or forensics: this structures the governance decision around an incident, not the response to it.

Maintain security metrics and KRIs as a living, trended record that persists in a local file, so the same numbers can be compared period over period. Define each metric with a required direction (higher-better or lower-better) and target/warn/critical thresholds, record dated readings with their source, and get deterministic direction-aware trend, threshold status, reading age, and the attention lists a metrics review works from — breached, worsening, stale, unowned, untagged, and vanity-flagged. Carries an archetype tag per metric that it resolves against ciso-board-translation at render time, cross-links to CSF Subcategories and register risks, and produces an operational review view plus a board section whose language comes from ciso-board-translation. Use when asked to track a metric or KRI, add this quarter's numbers, show how a metric is trending, judge whether a move between two readings is an improvement or a slip, find which metrics are breaching or going stale, or build the metrics section of a board pack. Do NOT use for a one-shot "translate this one number for the board" with nothing to store, or for questions about what a metric archetype means, what trap a kind of metric hides, or what the archetypes are — that content belongs to ciso-board-translation and is not duplicated here.