A technical reviewer working for a supervisory authority is not trying to break your platform. They are trying to establish, from documentation and answers, whether the firm understands its own risks and operates the controls it claims. That is a narrower question than a penetration test answers, and firms consistently prepare for the wrong one — arriving with a stack of technical reports and no ability to answer who approved the risk acceptance on finding fourteen.
This checklist covers what reviewers ask for, why, and what a good answer looks like.
1. A scope statement of your own systems
Before anything else, be able to state what systems exist, what each does, which hold customer data or move value, and where each runs. An asset inventory that is current and maintained is the single strongest signal a reviewer receives, because everything else depends on it. An inventory produced in the week before the review reads exactly like one produced in the week before the review.
2. Security testing history
Expect to provide assessment reports covering the current architecture, not an architecture two rewrites old. For each engagement, be ready to state: who performed it, what methodology they followed, what the scope boundary was, what was found, what was fixed, what was accepted and by whom, and whether closure was verified independently.
The verification point is where most firms are weak. "Fixed" in a ticket system is an assertion by the person who made the change. A retest report from the original assessor is evidence. If retesting has never been commissioned, say so plainly rather than presenting ticket closure as verification — reviewers read a lot of ticket exports and are not confused by them.
3. A risk register that has actually moved
Reviewers look for a register with dated entries, named owners, and evidence of items opening and closing over time. A register where every item is open, or every item is closed, or all entries were created on the same date, tells them the artefact was produced for the review rather than used in operation.
Accepted risks deserve particular care. Each should record what the risk is, why acceptance was chosen over remediation, who holds the authority to accept it, and when it will be revisited. An accepted risk with a named accepting officer and a review date is a functioning governance process. An accepted risk with no owner is a gap that has been renamed.
4. Access control evidence
Prepare to demonstrate: how access is granted, how it is reviewed, how it is removed on departure, how privileged access is separated from ordinary access, and how administrative actions are logged.
The strongest form of this evidence is a recent access review with exceptions recorded and resolved. The weakest is a policy document describing a review that has never demonstrably occurred. Leaver processing is examined closely because it is easy to verify and hard to fake: pick a person who left four months ago and show that every account was closed, with dates.
5. Incident history and response capability
Firms sometimes hope to present a clean sheet. A firm of any size and age reporting zero security incidents ever is read as a firm that does not detect incidents, which is worse than having had some.
Present the incident response plan, the escalation and notification paths including regulatory notification with its applicable clock, evidence that the plan has been exercised — a tabletop report is ideal — and post-incident reviews for incidents that occurred, with the actions they produced and evidence those actions completed.
6. Third-party and supply chain position
A register of third parties with access to systems or data, what each can reach, what due diligence was performed, what contractual security terms exist, and how the relationship is monitored. For critical providers, be able to answer what happens if they fail — not as a continuity abstraction, but concretely: which control stops operating, and what compensates.
7. Change and deployment control
How does code reach production, who can approve it, who can bypass the process, and is the bypass logged? Reviewers are interested in the emergency path specifically, because it is the one that exists everywhere and is documented almost nowhere. A firm that can show its emergency change path, its authorisation requirement and a record of the three times it was used last year is demonstrating control maturity more convincingly than any policy document.
8. Data handling and retention in practice
What personal and transaction data is held, where, for how long, and how deletion is performed. The recurring finding is deletion implemented in the primary store only, with copies persisting in backups, analytics warehouses, log aggregation and support tooling. Be able to describe the full data map, including the copies, and state the retention position for each rather than presenting a single policy figure that only applies to one system.
Preparing the answer, not just the documents
Three practices shorten a review substantially.
Assemble an evidence pack with an index. One document mapping each likely question to the artefact that answers it, with document names and dates. Reviewers work through a list; giving them the list mapped to your evidence removes several rounds of correspondence.
Nominate one technical respondent. Someone who can answer architecture, control and incident questions without escalating each one. Inconsistent answers from different people are read as a firm without a shared understanding of its own controls, and that impression is difficult to reverse.
State limitations before they are found. A firm that says "we have not yet performed an assessment of the internal administrative tooling; it is scheduled for Q3" is treated very differently from a firm whose omission is discovered by the reviewer. Volunteering a gap with a dated plan is evidence of self-awareness. Having it found is evidence of the opposite, and it changes how everything else you said is weighed.
