Security capabilities

Most compliance work asks the same underlying question over and over: do you have multi‑factor authentication? Are you logging? Do you scan for vulnerabilities? The Capabilities page turns that around. Instead of walking framework by framework, it looks at the tool categories your frameworks depend on and tells you, for each one, how many controls rest on it and whether 786 Cyber can already see it in place.

Find it from within Policy & Process → Compliance/CCM — Capability Gaps doesn’t have its own side-nav entry; it’s reached from the Compliance/CCM dashboard, alongside the Compliance Vault, so the nav doesn’t end up with three different “Vault”-style destinations competing for the same menu.

You need at least one assessment first. The analysis is built from the controls in the frameworks you’ve assessed, so until you’ve run an assessment the page will ask you to start one. See Compliance.

How to read the list

Each capability — MFA, vulnerability scanning, logging, cloud posture, and so on — is a row, ordered with the ones the most controls depend on at the top. The number on the right is that dependent‑control count across all your assessed frameworks. Open a row to see exactly which frameworks and which controls rely on it.

Every capability carries a status badge:

Status	What it means
Evidenced	786 Cyber has detected the capability in your own platform data — for example a vulnerability scanner is running, or MFA coverage is measurable.
Declared	You’ve said it’s in place, but there’s no automatic signal confirming it.
Unknown	No signal either way.

Honesty by design: a capability is only marked Evidenced when there is a real signal for it, and where there’s no signal it reads Unknown — never a red “you don’t have this”. The platform won’t invent a gap any more than it will invent a pass. And an evidenced capability still means the underlying control needs your review; detection is a strong hint, not a completed assessment.

How each gap is routed

A capability you don’t yet evidence isn’t just flagged — it’s routed to the way it actually gets closed, shown as a small label on the row:

• In‑platform — 786 Cyber has a module for this. Turn it on and the evidence lands automatically (for example, enabling a scan).
• Third‑party — it’s delivered by external tooling; the platform points you at what’s needed rather than pretending to do it.
• Documentation — no tool fixes this; it needs a policy or process document. These are collected separately under Documentation gaps at the foot of the page, and route to the policy generator.
• Process — an operational practice rather than a tool, listed under Process gaps.

Separating “buy or enable a tool” from “write a document” from “run a process” is deliberate: it stops a compliance gap from looking like a software problem when it’s really a paperwork one, and the other way round.

“You’re already covered elsewhere”

At the top of the page, when it applies, is a green panel that runs the logic in reverse. It looks at the capabilities you have evidenced and finds frameworks you haven’t assessed yet that those same capabilities would already cover — for example: “Your vulnerability scanning covers 18 controls in ISO 27001 — a framework you haven’t assessed yet.”

It’s the most useful part of the page for planning: it shows where you’d get compliance credit for work you’ve already done, so you can pick your next framework by how much of it is already in the bag.

Why it matters

For everyday security: it’s a single, prioritised view of the security capabilities that matter most to you — ranked by how much depends on them, not by vendor category — so you can see at a glance where the real thin spots are.

For compliance: it collapses the duplication out of multi‑framework work. One evidenced capability satisfies its dependent controls everywhere they appear, and the reverse view turns that into a roadmap for which framework to take on next.

---

Next: Policies & controls →