By the time you finish onboarding, CISO360AI has picked a framework, mapped a starting set of controls against it, and worked out a rough risk posture. That is a first draft, and none of it is your work yet.
So the first hour is not about building anything. It is about reading that draft and deciding what it got right, what it got wrong, and what it had no way of knowing. The walkthrough below is an example rather than a fixed script — your queue will look different from anyone else's — but the order of the work is real.
First, check the baseline you were given
First, know what you were handed. Onboarding asks roughly what a good CISO or an external auditor asks when scoping an engagement — who you are, what you hold, what you are trying to achieve — and which parts of the platform you want switched on. Then it does what follows from those answers: selects a framework, marks one as primary, seeds the baseline described below, and derives a first risk pass. Same reasoning either way. Minutes instead of a workshop, and written down as it goes rather than living in someone's notebook.
It also offers to walk you through scoring the requirements the baseline did not cover. That is optional, and it is the single highest-value thing you can spend the rest of the hour on.
One thing it does not settle, despite feeling like it should: your governance preferences — review cadence and target maturity — arrive later as a proposal you approve, not as an onboarding answer.
Which brings you to the sidekicks, and to the first one you will actually use.
Enter Faust, your CISO. Faust's job is the executive read: where the posture stands, how compliance is tracking, and what deserves board attention. Ask it to talk you through what onboarding produced. It is eager, it is fast, and it is working off a position it did not verify — so treat what it says as a claim to test rather than a result. The quickest way to learn something in this hour is to find the part that is wrong.
You will meet four more as you go, and they divide the way a security team does: Lex the compliance officer, who owns mapping, scores, gaps and remediation drafts; Sage the security analyst, for findings, vulnerabilities and CVE correlation; Janus the pentester, for attack surface and exposure; and Robin the incident responder, for scoping what is actually going wrong on an asset. You do not need to remember that list — each one turns up where the work does.
Next, the framework. Onboarding chose it from what you said about your sector, size and obligations, and your plan sets how many you can run at once. If something has changed since — a customer security review, a funding round, a new market — change it now, while there is no evidence attached to the wrong one.
Then the baseline. What onboarding seeds is deliberately narrow: one control for each thing the platform itself does, mapped to the requirements it covers, scored, and everything else left marked as a gap instead of quietly assumed. So it is accurate, and it is also not about your environment. That is the point. The platform vouches for its own part and leaves you the rest.
After that, changes arrive as proposals rather than edits. Each one carries a confidence score and waits in a queue, and by default nothing is applied automatically — auto-apply stays off until you switch it on. Your compliance position never moves unless someone agrees to it. It also means the queue is real work, so budget for it.
Requirements across frameworks are tagged against a shared NIST CSF spine. That is what lets one practice — multi-factor authentication on privileged accounts, say — line up against SOC 2 CC6.1, ISO 27001's access control requirements and the HIPAA Security Rule clause, instead of sitting in three unrelated rows. Scoring one framework from another's answers is a higher-tier feature, and most plans run the spine plus one framework, so expect the payoff later rather than on day one.
Then let the evidence come to you
Evidence is where compliance work usually goes to die: an inbox of half-answered requests to engineers, screenshots with no date on them, and a folder whose relationship to any particular control lives only in somebody's head.
Some of it now arrives on its own. Connect a cloud or productivity tenant and its configuration is checked continuously. Where a check answers a requirement, the result is attached as evidence and nobody exports anything. That covers the questions with a factual answer a machine can read.
The rest still needs you, and it is worth knowing which is which. Scan output — the asset inventory and external exposure Janus maps — arrives as findings you can attach. It does not file itself as evidence. Policy attestations, access reviews and anything where a person has to assert something are yours. The chasing goes away. Deciding what counts does not.
The fastest way through that manual half is not to do it in a browser. Point your own agent — Claude, Copilot, Cursor, whatever you already have open — at our MCP server, and it can work through the requirements with you and propose the links: this export answers that requirement, this attestation covers those three. Proposals are all it can do. Every link is a pending proposal until you approve it, so an agent with your repository and ticket history in context can move quickly without being able to assert anything on your behalf. That is a whole post of its own — see bring your own agent for the scoping and approval model.
Scanning live infrastructure is the one place the system stops and waits. It needs you to acknowledge the targets and accept the terms before anything runs, and every scan is recorded, so you can also answer what ran and when.
Whatever gets attached is timestamped and linked to the requirement it answers. That kills the most irritating audit finding there is: evidence that exists, is perfectly good, and was never connected to the thing it was meant to prove.
Then work the gaps in the order that matters
A gap here is a scored requirement that came back Not met or Partial — so the gap list is a direct read of the assessment rather than a separate inference, and it only says as much as the assessment does. Score honestly and it is useful; score optimistically and it agrees with you.
What comes back is ordered, not listed, and the ordering is the point, because a hundred unchecked boxes say nothing about which one will hurt. Not met sorts ahead of Partial, and within that, requirements already carrying linked findings sort ahead of ones nothing else in your data touches. That second signal is the useful one: it means something you are already failing operationally is also the thing your framework is asking about, which is a much better argument for fixing it than its position in a spreadsheet.
Each gap can then be turned into a remediation action with an owner attached — your default approver, or unassigned if you have not set one — and a starting description to replace. It is a stub with the routing already done, not a plan; there is no target date until you set one. Ask Faust to talk you through the result and you get something you can say out loud in a board meeting, and an executive overview report if you want the written artefact.
The correlation worth doing by hand is the one the ranking cannot see. Robin scopes incidents — affected assets, related findings and open vulnerabilities together — so when a gap looks serious, asking Robin what else is happening on that asset is the fastest way to find out whether it is one problem or three.
How the handoff fits together
Each sidekick's output is the next one's input, and you sit at the seams: approving, correcting, deciding. Against the manual version, the difference is less about speed than about where your attention goes.
| By hand | With CISO360AI | |
|---|---|---|
| Framework mapping | A crosswalk spreadsheet per framework, re-checked on every revision | Seeded baseline plus scored proposals in a review queue; nothing applied without your say-so |
| Requirements across frameworks | Reconciled by hand, one crosswalk at a time | Annotated against a shared CSF spine so the same practice lines up across them |
| Evidence | Chasing exports and screenshots, filed by hand | Connector configuration checks attach themselves; the rest you attach, all timestamped to a requirement |
| Gap analysis | Line-by-line against framework text | A direct read of what the assessment scored Not met or Partial |
| Prioritisation | A flat list, ordered by whoever wrote it | Not met before Partial, and requirements with linked findings before the rest |
| Remediation | A tracker built from scratch | An action per gap with the owner already routed, for you to fill in |
| Board reporting | Rebuilt by hand from raw findings | Talked through against live data, or generated as an executive overview |
| Elapsed time | Days to weeks, spread across a quarter | About an hour |
None of this removes judgement; it relocates it. Instead of running the mapping, chasing the evidence and formatting the report, the work becomes clearing the proposal queue, deciding what a scored requirement honestly deserves, signing off before a scan touches live infrastructure, and pushing back on the summary before it reaches an audience. What a good control looks like, what evidence holds up, what a board needs to hear — all of it matters exactly as much. It just gets spent on decisions instead of data entry.
Where to start
Finish onboarding and look at what it proposed. The fastest way to judge any of this is to see what the system says about your own environment, and how much of it you disagree with.
Start free or read the getting-started guide.