Vendor risk papers

1.  The Debrief

The call comes eighteen months after you approved the vendor.

It is not a routine check-in. The vendor has had an incident. Data was exposed. The scope is still being determined. Legal is on the line. Your regulator has sent a preliminary information request. The first question on the request is straightforward:

Provide documentation of your third-party risk assessment for this vendor, including the basis on which approval was granted and the evidence reviewed at the time of the decision.

You go to the system. You find the assessment. What you find is this:

—    A completed questionnaire — eighty-three questions, mostly Boolean, submitted by the vendor eleven days before approval.

—    A risk register entry showing GREEN, with a score of 74 out of 100, and the label 'Approved — Tier 2.'

—    An email thread in which a colleague wrote 'looks fine to me' and the CISO replied 'agreed, proceed.'

—    A SharePoint folder containing a SOC 2 Type II report, a penetration test summary, and a data processing agreement.

You send these to legal. Legal sends them to the regulator. The regulator replies with a follow-up:

Please confirm: (a) which specific controls were evaluated and on what evidentiary basis; (b) the methodology by which the score of 74 was derived; (c) the identity of the legal entity assessed; (d) who was accountable for the decision and under what authority.

This is where most organisations discover the gap. Not that the work wasn't done — it probably was, in some form. The gap is that no artifact exists which answers these questions. What exists is activity. What the regulator is asking for is a decision.

These are not the same thing.

2.  Why Questionnaires Feel Like Risk Management — But Aren't

The questionnaire became the default instrument of vendor risk management for understandable reasons. It is scalable. It creates a record. It asks questions. It generates a score. And in a world where regulators ask 'did you conduct due diligence,' a completed questionnaire is defensible evidence that something was done.

The problem is not the questionnaire. The problem is what questionnaire tools were designed to produce.

Questionnaire tools are optimised for collection. They are built to get answers back from vendors efficiently, to track completion, to store responses. They have no model for what an answer is worth. A vendor ticking 'Yes, we have a patch management policy' produces exactly the same output whether that claim is backed by an audited ISO 27001 certification, a policy document reviewed internally last quarter, or a Google Doc someone wrote the week before the assessment.

The tool records the response. It does not evaluate the evidence. It cannot distinguish between a claim and a proof.

Response completeness is not evidence sufficiency. This is not a gap in execution. It is a category error.

This distinction matters because regulators under FCA SS2/21, DORA Article 28, and equivalent frameworks do not ask whether vendors were questioned. They ask whether risks were assessed, whether controls were verified, and whether decisions were documented. Verification is a different activity from collection. Documentation is a different artifact from a completed form.

Most vendor risk programmes have built robust collection infrastructure and called it a verification programme. The two look similar from the outside. They produce very different results when examined from the inside — particularly under the forensic conditions of an incident debrief or a Section 166 review.

The organisations that discover this gap tend to discover it at the worst possible moment.

3.  Three Failure Modes

Vendor risk programmes fail under scrutiny in characteristic ways. These are not random failures. They are structural — produced reliably by the same design choices repeated across organisations, sectors, and tools. Understanding the structure of the failure is a prerequisite for building a programme that survives examination.

Failure Mode 1: Entity Identity Mismatch

You assessed a vendor. The question is: which one?

Most vendor risk programmes operate against brand names. You assessed 'Acme Cloud.' You have an entry in your risk register for 'Acme Cloud.' You have a folder of documents about Acme Cloud. But 'Acme Cloud' is not a legal entity. The legal entity providing your contracted service is Acme Cloud Services, a UK subsidiary of Acme Holdings GmbH, a German parent. The SOC 2 Type II you hold in your evidence folder was issued to Acme Holdings GmbH. The data processing agreement is with Acme Cloud Services. These are different legal persons.

In most incidents, this discrepancy is invisible until it becomes material. The moment a regulator asks which entity was approved, or a breach occurs and legal needs to establish who had contractual liability for the controls that failed, the mismatch surfaces. The evidence you hold does not cover the entity you contracted. Your assessment is attached to a brand, not a legal entity. It may not be defensible.

This is not an edge case. Vendor corporate structures are routinely complex, involve intermediate holding companies, and change through acquisition. Assessing the brand rather than the registered entity is the default behaviour of almost every vendor risk tool on the market, because almost no tool performs entity resolution — the act of establishing precisely which registered legal entity is the counterparty before any risk work begins.

You did not approve a brand. You approved a legal entity — or you should have. If you cannot say which one, the approval is incomplete.

Failure Mode 2: The Coverage Illusion

Evidence was received. The question is: what does it cover?

The SOC 2 Type II report is the most commonly misapplied piece of evidence in vendor risk management. Organisations treat its presence as a comprehensive signal of control maturity. In many cases, it is not.

A SOC 2 report covers a specific system boundary, a specific set of trust service criteria, and a specific time period. The audit opinion is valid for the scope described in the report — and only for that scope. An organisation using a vendor's SaaS application layer may receive a SOC 2 report that covers the vendor's data centre infrastructure, physical security, and network operations. If the application layer is explicitly excluded from the report's scope — a common feature of tiered service architectures — the evidence is real and the coverage is zero for the risk you are actually managing.

Most questionnaire tools have no model for coverage. Evidence is either present or absent. A document uploaded to the evidence folder is treated as covering the controls it was uploaded against. Whether the document actually speaks to those controls — whether its scope aligns with the service being contracted, whether exceptions noted in the report are material to your use case — is not evaluated. It is assumed.

The result is a confidence that is borrowed from a document that does not speak to the actual risk. The assessment looks complete. The protection is not there.

Evidence received is not evidence applied. Coverage is not implied by presence. A document in the folder is not the same as a control that is verified.

Failure Mode 3: Timestamp Decay

The decision was made. The question is: when, and to what state of the vendor's controls?

Vendor risk assessments have a shelf life. The evidence underlying an approval was accurate at a point in time. Controls change. Certifications expire. Audit findings from a SOC 2 report issued eighteen months ago describe the vendor's posture at the time of that audit — not now. The penetration test that satisfied your technical security requirements when the vendor was onboarded may cover a version of the application that no longer exists.

Most risk registers carry the approval forward indefinitely, or until a reassessment is manually triggered. The GREEN status that was valid at the time of approval continues to display against the vendor record regardless of what has changed in the intervening period. When an incident occurs, the register shows GREEN — because nobody updated it, because nothing triggered a reassessment, because the platform has no model for evidence decay.

But the deeper problem is not the stale status. It is that even if a reassessment was triggered and completed, there may be no frozen record of what was known at the moment the original approval was given. If legal asks 'what did you know about this vendor's patch management controls at the time of the incident,' and the answer is 'we cannot reconstruct that because the assessment was overwritten by the renewal,' the original approval is effectively undocumentable.

An approval without a frozen, timestamped record of the state of knowledge that supported it is not a decision. It is a historical event with no surviving artifact.

4.  What a Decision Actually Requires

The three failure modes above are not independent. They share a common root: vendor risk programmes have been designed around the process of assessment rather than the production of a decision. The output of most programmes is an approval. That is not the same as a decision — at least not a defensible one.

A defensible vendor decision requires four things that questionnaire collection cannot provide.

Legal entity certainty

The decision must be attached to a specific registered legal entity — not a brand name, not a trading name, not a product. The counterparty to the contract, the entity whose controls are relevant, the organisation that a regulator can identify and investigate, must be established before any risk work begins. This is not administrative hygiene. It is the foundation of everything that follows. Evidence that does not attach to the correct entity does not cover the risk you approved.

Evidence with evaluated coverage

Evidence must be evaluated on two axes: how strong the evidence type is, and how much of the relevant control it actually covers. An audited certification is stronger than a vendor attestation. An attestation that covers the full control is more valuable than a certification that covers half of it. These are not binary distinctions. They require a model — a methodology for translating evidence into a confidence level that is derivable, explainable, and consistent. 'We reviewed the documents and were satisfied' is not a methodology. It is a judgment. Judgment is not reproducible. Reproducibility is what makes a decision defensible.

A frozen, timestamped record

The state of knowledge at the moment of decision must be permanently captured. Not as a status in a live system that reflects the current view of the vendor, but as an immutable artifact that records what was assessed, what evidence was evaluated, what confidence was derived, and what decision was reached — at a specific point in time, against a specific version of the vendor's controls. This record must survive platform migrations, vendor reassessments, and changes in personnel. It must be retrievable years after the decision was made. It must not be editable after the fact.

A derivable output

The decision must follow from the inputs by a methodology that can be explained and replicated. Given the same evidence, evaluated against the same controls, the same conclusion must be produced — not because the system forces it, but because the methodology is consistent enough that another reasonable assessor, given the same information, would reach the same result. This is what 'defensible' means in the context of a regulatory inquiry. Not that the decision was correct, but that it was reasoned — that it was the product of a process that a regulator can examine, follow, and evaluate.

These four requirements describe a decision engine — not a questionnaire tool. The category of tool most organisations are using is simply the wrong tool for the job they believe they are doing.

5.  Determinism as a Legal Property

The word 'deterministic' sounds like a technical property. It is not. Or rather, it is not only that.

In engineering, determinism means that a system given the same inputs always produces the same outputs. In the context of vendor risk, this property has a legal significance that is often missed: it is the foundation of reproducibility, and reproducibility is the foundation of accountability.

Consider what a regulator or auditor is actually asking when they review a vendor decision. They are not, primarily, asking whether the decision was correct. They are asking whether the decision was made — whether it was the product of a defined, consistent methodology applied to a specific body of evidence, rather than the accumulated judgment of people who have since left the organisation, applying criteria that were never written down.

Judgment-based programmes fail this test structurally. Not because the people exercising judgment are incompetent or negligent, but because judgment is inherently personal, contextual, and non-reproducible. One assessor sees a SOC 2 with two minor exceptions and rates the vendor Moderate. Another assessor, at a different organisation, or in a different week, sees the same report and rates it High. Both are exercising reasonable professional judgment. Neither is producing a defensible decision, because neither is applying a methodology that could be examined and validated by a third party.

A deterministic methodology does not eliminate judgment. It structures it. It defines where judgment operates — in the design of the methodology — rather than in the application of it, assessment by assessment, vendor by vendor, assessor by assessor.

This matters for a specific regulatory reason. FCA SS2/21 requires firms to demonstrate that their outsourcing risk frameworks produce consistent, documented outputs. DORA Article 28 requires that ICT third-party risk assessments are conducted according to a defined methodology. Neither regulation prescribes what the methodology must be. Both require that one exists, that it is applied consistently, and that its outputs can be produced on request.

A deterministic risk engine satisfies this requirement structurally. The methodology is encoded, not described. The outputs are produced by the methodology, not by the assessors applying it. The same vendor, assessed under the same conditions, will always produce the same result. This is not a constraint on human judgment — it is the infrastructure that makes human oversight accountable, rather than merely present.

The override exists — there will be cases where a senior leader needs to approve an exception to a hard gate, where business requirements require accepting a risk that the methodology would block. But the override is structured, time-limited, and auditable. It is an explicit act of governance, not an invisible exercise of discretion. The exception is documented. The rule is preserved. And the documentation of the exception is itself part of the decision record.

6.  The Artifact That Survives the Platform

Dashboards go stale. Risk registers reflect the current state, not the historical one. Scores in live systems are updated when new information arrives, overwriting the basis on which the original decision was made. Personnel change. Platforms are migrated. Evidence folders are reorganised. Emails are archived. And the institutional memory of why a vendor was approved, on what basis, with what caveats, under whose authority — dissipates.

What survives is a document.

Not a dashboard screenshot. Not a PDF export of a live report. A document that was generated at the moment of decision, frozen at that moment, containing a complete record of the state of knowledge that supported the decision: the legal entity assessed, the controls evaluated, the evidence reviewed and its coverage, the confidence derived, the decision reached, the person accountable, the timestamp. And a cryptographic hash — a fingerprint that allows any third party, at any point in the future, to verify that the document has not been altered since it was generated.

This document is what the industry has spent years generating activity to support — and consistently failing to produce.

The activity is real. The questionnaires are completed. The evidence is collected. The scores are calculated. The approvals are given. But the decision — the artifact that survives — is not there. What exists is a trail of inputs. What is missing is the output that a regulator can examine, a court can admit, an auditor can verify, and a board can understand.

The purpose of a vendor risk programme is not to conduct assessments. It is to produce defensible decisions. These are related activities. They are not the same activity.

Organisations that have built their programmes around collection — gathering responses, filing evidence, maintaining registers — have built infrastructure for the first activity. They have not built infrastructure for the second. The gap is not visible during normal operations. Risk registers look healthy. Scores look reasonable. Approvals are on file. The gap becomes visible at the moment of examination — an incident, an inquiry, a regulatory review — when the question shifts from 'did you assess this vendor' to 'show me the decision.'

That shift is not a new regulatory development. It is not the product of increased enforcement activity or changing guidance. It is the natural consequence of any event that requires accountability to be traced back to a specific act, by a specific person, on a specific basis, at a specific time.

The vendor risk programmes that survive these moments are the ones that produce decisions, not approvals. Decisions that are reasoned, reproducible, frozen at the moment they are made, and attached to the correct legal entity. Decisions that exist as artifacts independent of the platform that produced them.

Everything else is activity. Activity is necessary. It is not sufficient.

About this paper

This paper was written for risk, compliance, and audit professionals in FCA-regulated financial services and institutions subject to DORA. It does not advocate a specific product or vendor. It examines a structural problem that is, in our view, underdiagnosed — and consequential in proportion to how long it goes unaddressed.

KnightGrid builds deterministic vendor risk infrastructure for regulated financial institutions. If the arguments in this paper resonate with your experience, we would welcome a conversation.

The Document That Arrives

It does not come as a phone call. It comes as a letter, or a secure email, formatted with the precision of something that has been drafted by lawyers and reviewed by compliance officers before it reached you. The subject line names your firm. The body references a third-party incident — one you are already aware of, or one you are about to become aware of.

The letter asks for documentation. It specifies a timeline — typically ten to fifteen working days. It instructs that responses must be supported by contemporaneous records: documents that existed at the time of the events in question, not reconstructions produced in response to the request. And it contains, in some form, the same five questions that appear in almost every regulatory information request following a third-party vendor incident.

The questions are not difficult questions. They do not require specialist knowledge to understand. They are the minimum — the baseline from which a regulator determines whether to ask harder ones, extend the review, or escalate.

What follows is an examination of each question, and of why most vendor risk programmes, built on the tools and processes that dominate the market, cannot answer them.

The questions are not difficult. The infrastructure required to answer them is not present in most organisations. These are different problems with the same consequence.

*1. ** Which legal entity did you approve?*

You go to the risk register. You find the vendor. The entry reads: 'Vertex Analytics — Approved — Tier 2 — Last assessed: March 2025.'

The letter from the regulator references a different name. It references Vertex Analytics (UK), company number 11847362, registered at an address in Leeds. You search the register for that name. It is not there. You search for the company number. It is not there either.

You go to the contract. The counterparty is Vertex Analytics (UK). You go to the SOC 2 report in the evidence folder. It is issued to Vertex Analytics Inc., a Delaware corporation. You go to the data processing agreement. It names Vertex Analytics Group Holdings BV, a Dutch entity.

Three legal persons. One vendor record. No certainty about which entity was assessed, which entity's controls were reviewed, or which entity the approval was actually granted to.

You did not approve a brand. You approved — or should have approved — a specific registered legal entity. If you cannot say which one, the approval is, at minimum, incomplete. Under FCA SS2/21 and DORA Article 28, it may not constitute a documented assessment at all.

This is not an unusual situation. It is the default condition of vendor risk programmes built around brand names rather than legal entities. Almost no vendor risk tool on the market performs entity resolution — the act of establishing, before any risk work begins, precisely which registered legal entity is the counterparty to the contracted service. The tool creates a record for 'Vertex Analytics.' It does not ask which Vertex Analytics. It does not cross-reference the Companies Register. It does not flag that the entity named in the contract differs from the entity that issued the assurance documentation.

The result is a vendor record that floats above the legal reality of the relationship. It looks complete. It is not attached to anything that a regulator can verify, a court can subpoena, or an auditor can trace to a specific registered person.

When the question arrives — which legal entity did you approve — the honest answer, in most organisations, is: we are not certain.

*2. ** What evidence did you review, and what did it cover?*

You find the evidence folder. It contains four documents: a SOC 2 Type II report, a penetration test executive summary, a completed vendor questionnaire, and a data processing agreement. You send these to the regulator as the basis for the approval.

The regulator comes back with follow-up questions. They are specific.

—    The SOC 2 report: what was the system boundary? Was the service you contracted — specifically the data analytics API and its underlying processing infrastructure — within scope of the audit opinion?

—    The penetration test: what was the date of testing? What version of the application was in scope? Was retesting conducted after identified vulnerabilities were remediated?

—    The vendor questionnaire: was this self-attested or independently verified? What evidence was provided to support the responses?

—    The data processing agreement: this is a contractual instrument, not an assurance document. What controls verification does it constitute?

These are not hostile questions. They are the natural consequence of asking what evidence was reviewed and what it covered. They distinguish between evidence that was received and evidence that was applied — between documents that exist in a folder and controls that were actually verified.

The SOC 2 report, on examination, covers Vertex Analytics' data centre operations and physical security controls. The service boundary explicitly excludes the SaaS application layer — the component you are actually using. The penetration test is nineteen months old and covers a version of the application that has since been substantially rewritten. The questionnaire responses are self-attested with no supporting evidence required or provided. The DPA is a contract.

None of these documents, individually or collectively, constitute verified evidence that the controls relevant to your specific use of the vendor — the controls that relate to the risk that materialised — were operating effectively at the time of the incident.

Evidence presence is not evidence coverage. A document in the folder is not the same as a control that is verified. Most risk registers have a field for the former. Almost none have a model for the latter.

Coverage — the mapping of a specific piece of evidence to a specific control, evaluated for scope alignment, independence, and the degree to which the evidence actually speaks to the risk — is not a concept that exists in most vendor risk tools. Evidence is either present or absent. The assumption is that presence implies coverage. That assumption does not survive regulatory examination.

*3. ** What was your confidence level, and how was it derived?*

The risk register shows a score of 71 out of 100, a rating of Medium Risk, and a status of Approved. The regulator asks for the methodology underlying the score.

This is the question most risk teams are least prepared for. Not because the score doesn't exist — it does, it's in the register — but because the question is not about the score. It is about the function that produced it.

—    What inputs were fed into the scoring model?

—    What weight was assigned to each input?

—    What threshold determined the boundary between Medium and High?

—    Was the same methodology applied to all vendors assessed in the same period?

—    If two assessors, given the same evidence, applied this methodology independently, would they produce the same score?

The last question is the critical one. It tests whether the methodology is a methodology — a defined, consistent function — or whether it is professional judgment, applied differently by different people on different days, and called a score to give it the appearance of precision.

If the answer to that last question is no — if two assessors would produce different scores from the same evidence — then the score is not a measurement. It is an opinion expressed as a number. And an opinion expressed as a number is not more defensible than an opinion expressed as a judgment. It is less defensible, because it implies a rigour that does not exist.

Regulatory frameworks do not prescribe what your methodology must be. They require that one exists, that it is applied consistently, and that its outputs can be explained. A score produced by judgment is not a methodology. It is a number with a story behind it that changes depending on who tells it.

The scoring models embedded in most questionnaire tools are opaque by design. They produce a number. They do not expose the weights, the thresholds, or the logic by which the number was reached. A vendor with a score of 71 may have arrived there through a completely different combination of inputs than a vendor with an identical score assessed the following quarter. The tool treats them as equivalent. They are not.

When a regulator asks how the confidence level was derived, and the honest answer is 'the tool calculated it, we are not certain of the exact methodology,' the programme has failed the test that matters most: demonstrating that the decision was the product of a defined, explainable, reproducible process.

*4. ** Who was accountable for the decision, and under what authority?*

You find the approval. It is a Slack message from the CISO that reads: 'yeah this one looks fine, go ahead.' It is timestamped fourteen months ago. The CISO left the organisation eight months ago.

Or: the approval is a status change in the risk register from 'Under Review' to 'Approved,' made by a user account that belongs to a vendor risk analyst who has since moved teams. There is no record of who authorised the change, or whether it required sign-off from someone more senior.

Or: the approval is an email thread in which three people discussed the vendor over four days, and the final message says 'I think we're good to proceed' — from someone whose authority to make that determination is not documented anywhere.

Approval and accountability are not the same thing. An approval can exist without a named accountable person, without a record of the authority under which it was given, and without a trail that connects the decision to the governance framework that was supposed to govern it.

FCA SS2/21 requires firms to maintain records that identify who is responsible for managing each material outsourcing arrangement, and under what governance structure. DORA Article 28 requires that ICT third-party risk assessments are subject to documented oversight. Neither regulation is satisfied by a Slack message, a status change, or an email thread in which consensus was reached informally.

The regulator's question is not 'who clicked approve.' It is: who was accountable for this decision, what authority did they have to make it, was the correct escalation path followed under your firm's outsourcing policy, and was any of this documented at the time?

In most organisations, the escalation path exists in a policy document. It specifies that Tier 1 vendors require CISO sign-off, that Tier 2 require Head of Risk, that any vendor with access to personal data above a certain volume requires board-level notification. The policy is real. The documentation that the policy was followed — for this vendor, on this date, by this person — often is not.

What the regulator finds is an approval without an accountability chain. The decision happened. The governance that was supposed to govern it left no trace.

*5. ** What is the current state of your evidence, and when did you last verify it?*

The incident occurred six weeks ago. The regulator asks about the state of the vendor's controls not at the time of initial approval — that is Question 2 — but at the time of the incident. Specifically: what evidence did you hold at the time of the incident, when was that evidence generated, and does it cover the controls relevant to the risk that materialised?

The risk register shows the last assessment date as March 2025. It is now late 2026. The assessment has not been renewed. The SOC 2 report in the evidence folder expired in June 2026 — it was issued for the period ending June 2025, with a twelve-month validity. The penetration test has not been refreshed since the original onboarding. The vendor questionnaire has not been resubmitted.

For nineteen months, the register has shown Approved. The evidence underlying that approval has decayed — some of it has lapsed entirely — but the status has not changed. There is no record of the evidence expiry being flagged, of a reassessment being triggered, or of anyone reviewing whether the original confidence level was still warranted.

The risk register carries the approval forward. It does not carry the confidence forward. These are not the same thing. An approval granted on the basis of evidence that no longer exists is not an approval that can be defended.

Most risk registers have a field for last assessment date. Very few have a model for evidence decay — the rate at which different types of evidence lose their assurance value over time. A SOC 2 Type II is typically valid for twelve months. A penetration test has a shorter effective life in a changing codebase. A vendor self-attestation without independent verification has a shorter life still.

When certifications expire, most tools do nothing. There is no automated flag, no status change, no triggered reassessment. The approval remains live. The evidence that supported it no longer does.

The regulator's question — what is the current state of your evidence — cannot be answered by showing the original assessment. It requires a monitoring record: evidence that the firm was tracking the ongoing state of vendor controls between assessments, that expiries were flagged, that material changes were investigated. For most organisations, no such record exists.

The approved vendor list is not a monitoring programme. It is a list of things that were approved, at some point, on some basis. Whether that basis still holds is a question most programmes are not structurally equipped to answer.

The Structural Diagnosis

Five questions. None of them are unreasonable. None of them require information that a well-designed programme would not naturally produce. They ask for the legal entity that was approved, the evidence that was reviewed and what it covered, the methodology that produced the confidence level, the accountability chain that governed the decision, and the ongoing monitoring record that tracks whether the approval remains warranted.

A programme that cannot answer these questions is not a programme that made poor decisions. It is a programme that was designed to conduct assessments rather than to produce decisions — and assessments, however thorough, do not generate the artifacts that decisions require.

The infrastructure of assessment — questionnaire distribution, response collection, evidence filing, score calculation, approval recording — is necessary but not sufficient. It produces a trail of inputs. What is missing, in most programmes, is the output: a documented decision that names the legal entity, records the evidence with its coverage, derives the confidence through an explainable methodology, identifies the accountable person and their authority, and captures a point-in-time state of knowledge that is frozen at the moment of decision and does not decay silently as time passes.

The five questions expose this gap. They do so reliably, across sectors and firm sizes, because the gap is structural. It is not produced by negligence or underinvestment. It is produced by using the wrong category of tool for the job — collection infrastructure applied to a problem that requires decision infrastructure.

The regulator is not asking whether you assessed the vendor. They are asking whether you made a decision. The distinction is precise. So is the gap between what most programmes produce and what those questions require.

The organisations that answer these questions without difficulty are not necessarily the ones with the largest risk teams or the most sophisticated security programmes. They are the ones whose vendor risk infrastructure was designed around the decision rather than around the assessment — whose output is a frozen, hashed, accountable artifact rather than a live register entry that reflects the current state of a relationship rather than the documented state of a decision.

That is a design choice. It is available. Most programmes have not made it.

About this paper

This is the second paper in the KnightGrid Academy series. The first paper, The Approval That Wasn't a Decision, examined the structural difference between conducting an assessment and producing a defensible decision. This paper applies that argument to the specific questions that regulatory information requests produce. The third paper will examine what vendor risk infrastructure designed around the decision — rather than the assessment — looks like in practice.

KnightGrid builds deterministic vendor risk infrastructure for FCA-regulated financial institutions and firms subject to DORA. If the arguments in this series are useful to you, we would welcome a conversation.