Frameworks are the starting point. Operating them is the work.
We design risk programs to be run, not filed: controls specified to the point of evidence, mapped once across the standards that apply, monitored continuously, and reported in terms a committee can act on.
- Controls designed to be operated and evidenced
- Mapped once across the frameworks that apply
- Monitored between assessment cycles
- Reported as exposure, not as activity
Used for control mapping and readiness work. No affiliation with, or endorsement by, the issuing bodies is implied.
- ISO 27001
- ISO 31000
- NIST CSF
- NIST 800-53
- SOC 2
- COBIT
- COSO
- DORA
- PCI DSS
- GDPR
Both lines, working from the same risk reality.
Risk ownership sits with the first line and oversight sits with the second. Our work is almost always in the space between them.
The teams that take risk as part of doing the work — and that have to absorb the consequences when a control fails.
- Business
- Operations
- Technology
- Product
- Procurement
- Fragmented information
Vendor facts live in procurement, security and finance systems.
- Manual assessments
Questionnaires re-sent, re-answered and re-read every cycle.
- Unclear ownership
Findings raised against a function rather than a named owner.
- Remediation delays
Actions agreed in a forum, then tracked in nobody's backlog.
- Duplicated controls
The same control tested three times for three frameworks.
- Vendor exposure
Concentration and fourth parties visible only after an incident.
The functions that set the framework, challenge decisions, test controls and hold the aggregate view of exposure.
- Operational Risk
- Information Security
- Compliance
- Third-Party Risk
- Technology Risk
Both lines are doing their job. They are simply working from different systems, different definitions and different versions of the truth — and the distance between them is where exposure accumulates.
Designed to be operated, not documented.
Control work fails in one of two ways: controls that cannot be evidenced, or the same control tested three times for three frameworks. Both are solvable at design time.
Control design
A control is a specific action, performed by a named owner, at a defined frequency, leaving evidence behind. Anything short of that is a statement of intent.
- Control objectives & statements
- Owner and frequency definition
- Preventive / detective balance
- Evidence requirement design
- Control library construction
- Risk-to-control mapping
Control testing
Design effectiveness and operating effectiveness assessed separately, with sampling and criteria agreed before the test rather than after the result.
- Design effectiveness review
- Operating effectiveness testing
- Sampling methodology
- Deficiency rating criteria
- Compensating control analysis
- Re-test and closure validation
Framework mapping
One control set, mapped across the standards you have to answer to, so evidence is produced once and reused rather than recollected per audit.
- Cross-framework control mapping
- Gap assessment against target state
- Overlap and duplication removal
- Policy-to-control traceability
- Coverage reporting
- Framework change impact analysis
Remediation programs
Gaps turned into a sequenced program with owners and dates, prioritised by exposure rather than by how easy the fix is to describe.
- Prioritised remediation roadmap
- Owner and milestone definition
- Interim and compensating controls
- Progress and blockage reporting
- Validation of closure
- Post-remediation monitoring
Test once. Satisfy several.
A single well-specified control usually answers requirements across every framework in scope. Mapping it deliberately is the difference between one evidence cycle and four.
Risk changes every day. Your assessment process should too.
An annual questionnaire tells you what a vendor believed about itself on the day it was completed. Everything material — a certificate lapsing, a new subprocessor, an SLA trend, a disclosed vulnerability — happens in between.
Traditional risk management
Accurate on the day it was signed. Increasingly theoretical after that.
- Annual questionnaire
- Spreadsheet of record
- Static risk score
- PDF evidence attached to email
- Periodic review, once a year
- Exposure known at a point in time
Continuous risk management
The picture updates when your exposure updates, not when the calendar does.
- Risk signals as they occur
- Control status monitoring
- Vendor and subprocessor changes
- Evidence with an expiry date
- Live remediation tracking
- Exposure known today
Thirty days in the life of one Tier 1 vendor
Move from periodic assessments to continuous risk awareness.
- D+0ISO 27001 certificate expires+6
Payments processor · Tier 1 · evidence now stale
- D+3Critical vulnerability disclosed+11
Affects the data platform used by two Tier 1 vendors
- D+9Vendor adds a subprocessor+7
New fourth party in a region outside the approved scope
- D+14SLA breach recorded+5
Third consecutive month below the contractual threshold
- D+21Control evidence goes out of date+3
Access recertification not produced for the current quarter
- D+27Remediation validated-14
Vendor closes two high findings · re-tested and accepted
Aggregate exposure index · Tier 1 population
- Signals received
- 0
- Requiring action
- 0
Illustrative. The profile moves as evidence, findings and vendor changes arrive.
From strategy to execution.
Three ways to work with us. Most clients move between them — a framework designed in advisory becomes an assessment programme, and the steady-state runs as risk operations.
Advisory
Design the operating model.
Risk taxonomies, frameworks, policies, methodologies, tiering models, governance forums and target operating models — specified in enough detail that they can be run the day after we hand them over.
- Risk & control framework
- TPRM methodology and tiering model
- Governance and escalation design
- Target operating model & roadmap
Assessment
Establish the facts.
Focused, time-boxed assessments of a vendor, a platform, a process or a control set. Findings are written to be actionable by the team that owns the remediation, not only by the risk committee.
- Vendor & critical supplier assessments
- Technology and cloud risk reviews
- Control design & effectiveness testing
- Gap analysis against target frameworks
Risk Operations
Run it with us.
A named team operating defined parts of your risk program under your governance: assessment queues, evidence review, reassessment cycles, remediation follow-up and reporting.
- Managed assessment queue
- Evidence and questionnaire review
- Remediation tracking & escalation
- Recurring risk & board reporting
A vendor lifecycle, with ownership on every step.
Programs stall where a step has no owner. This is the third-party lifecycle we implement most often — each stage annotated with the line accountable for it.
- 1st Line
- 2nd Line
- Both lines
- 01
Vendor onboarded
Business need, data scope and process dependency captured at intake.
- 02
Criticality assessment
Impact on critical services, data classification and substitutability.
- 03
Risk tier
Tier drives assessment depth, evidence set and reassessment frequency.
- 04
Due diligence
Security, resilience, privacy, financial and concentration review.
- 05
Evidence review
Certifications, reports and configuration read against the control set.
- 06
Findings
Rated against defined criteria, with a named owner on the first line.
- 07
Remediation
Actions, dates and compensating controls tracked to closure.
- 08
Approval
Residual risk accepted at the right level, with the rationale recorded.
- 09
Continuous monitoring
Signals, expiries and vendor changes update the profile between cycles.
- 10
Reassessment
Triggered by tier, by material change, or by the risk picture itself.
Step 10 returns to step 02 — reassessment is a trigger, not a date in a calendar.
Demonstrating that the process actually operates.
Readiness is not a document exercise. It is the ability to show, on request, that a control ran, who ran it, what it produced and what happened when it failed. We prepare organizations for that conversation — we are not an auditor or a certification body.
Evidence organised before it is requested
A structured repository with control, period, owner and validity recorded — so a request results in a retrieval rather than an investigation.
Traceability from policy to evidence
Policy statement to control to owner to evidence to test result. When any link is missing, the control is not demonstrable regardless of how well it operates.
Findings answered once
Response drafted with the remediation plan attached, so a finding closes on the first cycle rather than generating a second round of questions.
A defensible record of decisions
Risk acceptances recorded with rationale, evidence, expiry and approving authority. Reconstructing this after the fact is where most programs lose credibility.
Put the method to work on a real program.
Start with a review of the current control set, a framework gap assessment, or a design engagement for a program that has to stand up to scrutiny.