The checks run. The reports arrive. But no one ever defined the structure underneath: what gets verified, to what standard, under whose accountability. That is not a programme. That is an accumulation.
Procurement issued an RFP. Vendors responded. A contract was signed. Checks started running.
At no point did anyone define what the programme was supposed to achieve.
Not the verification depth each role type requires. Not the evidence standard that would hold under audit. Not the methodology that works in each corridor. Not who is accountable for quality. Not how data flows across jurisdictions.
Those decisions were never made. They were inherited.
The vendor's default configuration became your architecture. The vendor's limitations became your constraints. The vendor's definition of "verified" became your standard of proof.
Nobody questioned whether that standard is sufficient.
This is not a vendor failure. The vendor delivered what was contracted. It is a specification failure: you purchased what was offered because what was needed was never defined.
Rate each dimension based on what your organisation has documented and enforced, not what you assume is in place. If the answer requires checking with someone else, the honest answer is probably "Partial" or "Not defined."
The rest of this page explains what each dimension means, why it matters, and what happens when it is left undefined. Your score above is the starting point.
Click each card to reveal the reality behind the assumption.
"We have a screening programme in place."
The organisation runs background checks on new hires. Reports are delivered. Dashboards show completion rates. There is a vendor, a contract, and a process.
The organisation has a vendor relationship, not a programme.
The checks that run are determined by what was included in the original vendor proposal. Nobody has reviewed whether those checks are appropriate for every role type, in every corridor, under current regulatory requirements.
"Our checks are comprehensive."
The vendor runs a multi-check package. Employment, education, criminal, identity, and address verification are included. The coverage looks thorough.
The same package runs in every corridor.
A criminal check that requires physical court access in one jurisdiction runs as a database search in another. Both are reported as "criminal check: completed." The methodology gap is invisible in the dashboard.
"Our vendor is compliant."
The vendor has ISO 27001 certification, a SOC 2 report, and a signed DPA. Compliance boxes are checked.
The vendor's compliance certifications describe the vendor's posture, not the programme's outcomes.
Whether the actual processing matches the documented processing is a question nobody has tested. The DPA describes a data flow that has not been validated against operational reality in over a year. And the reports that say "verified" do not show who was contacted, what was confirmed, or who made the determination. Under scrutiny, that is not evidence. It is a claim.
These gaps are not caused by vendor negligence. They are caused by the absence of programme architecture. When the programme's requirements are never defined, the vendor's defaults become the standard. When the standard is never documented, it is impossible to assess whether it is being met.
It is not a vendor evaluation, a compliance checklist, or an RFP template. It is the set of decisions that must be made before any of those activities produce meaningful results: what gets checked, to what depth, through what method, under whose accountability, with what evidence, and how it is governed.
Verification depth decided by the vendor. Evidence standard inherited from the contract. Accountability assumed but undocumented. Data handling described in a DPA that nobody has validated. Governance: none.
Verification depth defined per corridor and role. Evidence standard documented to audit grade. Accountability assigned with escalation paths. Data handling mapped and validated. Governance cadence active and enforced.
The next section defines each of these five dimensions and what happens when they are left unspecified.
Each dimension is interdependent. Defining one without the others results in an incomplete architecture that breaks under operational pressure or regulatory scrutiny.
What is checked, to what depth, through what method, in each corridor, for each role type. This is not a check list. It is a verification matrix that maps role risk to verification rigour, adjusted for each jurisdiction's regulatory requirements, source availability, and methodological constraints.
A criminal record check in India is not the same as a criminal record check in the Philippines. The verification method, source, timeline, and evidentiary value are different. The verification standard specifies what "criminal check" means operationally in each corridor, so the output is comparable and the evidence is defensible.
What documentation is produced for each check, at what level of granularity, in what format, with what retention. The evidence standard defines the difference between a check that was processed and a check that is defensible.
A defensible check has a timestamped record of who was contacted, by what method, on what date, what response was received, what was confirmed, what was not, and the identity of the analyst who processed it. A processed check has a summary that says "verified." Under scrutiny, only one of these withstands examination.
Who is responsible for verification quality, exception handling, escalation protocols, and compliance integrity. The accountability structure defines who decides what happens when something goes wrong, not just who processes the check.
When an employer does not respond to a verification request, who determines the follow-up protocol? When a check returns ambiguous results, who decides whether to escalate? When a case is closed as "unable to verify," who is accountable for that determination and the documentation that supports it?
Where candidate data flows, through which entities, in which jurisdictions, under which legal basis, with what consent, and with what documentation. This is not a data processing agreement. It is a verifiable map of how data actually moves through the screening process.
The data handling framework specifies every entity that touches candidate data, the jurisdiction in which processing occurs, the legal basis for each processing activity, the consent mechanism and its evidentiary standard, and the retention and disposal schedule. When a regulator asks "who processed this data and under what authority," the answer is produced from the framework, not reconstructed from memory.
How the programme is monitored, what is measured, how deviations are identified, and what triggers corrective action. The governance model transforms the programme from a process into a controlled system.
This includes: what quality metrics are tracked beyond completion rates, how verification depth is audited across corridors, what triggers a programme review, who receives reporting on compliance integrity (not just operational throughput), and how the architecture itself is updated as regulatory requirements change or corridors are added.
These are not theoretical risks. Each one is a pattern that recurs in organisations with established screening programmes, reputable vendors, and compliance teams who believed the programme was sound. Click to expand each consequence.
The India corridor runs seven checks with source verification. The Philippines corridor runs four checks with database-only methods. Both produce 98% completion rates. An auditor asks why the same role receives different verification rigour by geography. The answer is: nobody designed it. It accumulated through separate procurement decisions.
A post-incident review requests the verification chain for a specific hire. The screening report says "verified." The review asks: who was contacted, when, what was confirmed. The vendor's documentation does not contain this information. The check was processed. It was not documented to an evidentiary standard. The vendor delivered what was specified. The specification was insufficient.
A regulator asks: who processed candidate data, in which jurisdiction, under what legal basis, with what consent? The compliance team provides the DPA. The regulator asks for evidence that the documented processing matches actual processing. The sub-processor list was last updated 18 months ago. Two processors have changed. The data flow described in the DPA no longer reflects operational reality.
A major client conducts third-party risk management due diligence on your organisation. They ask for evidence of your screening programme's compliance controls. The evidence you produce is a vendor summary report and a contract. The client asks for the verification methodology, evidence standards, and accountability structure. You do not have these documents because they were never created.
The organisation expands into a new market. The vendor adds the corridor. The checks that run are determined by the vendor's default package for that country. Nobody assesses whether those defaults meet the regulatory requirements, the risk profile of the roles being filled, or the evidence standard that the rest of the programme is supposed to maintain. The new corridor operates on different assumptions. The divergence is invisible.
An organisation runs screening across eight corridors: India, Philippines, Malaysia, Vietnam, Poland, Colombia, South Africa, and the UAE. They use a single vendor. The programme has been operational for three years. Completion rates average 96%. Turnaround times are within SLA. The programme appears to be working.
A structural review reveals: four corridors use source verification for employment history; four use database-only methods. Criminal checks in three corridors rely on national databases that do not cover sub-national jurisdictions. Education verification in two corridors is performed through a third-party aggregator whose data freshness is unvalidated. Consent collection in the EU corridors follows GDPR requirements; consent in the APAC corridors follows the same template, which does not address local data protection laws. The vendor changed a sub-processor nine months ago; the DPA still references the previous one.
None of this was caused by the vendor acting in bad faith. The vendor delivered the programme as specified. The specification was assembled over three years, by three different procurement leads, with no overarching architecture. The programme was never designed. It was inherited.
Estimated remediation: 12 to 16 weeks to re-scope all eight corridors, re-validate evidence standards, update data handling documentation, and establish a governance baseline. This is the cost of retroactive architecture.
Programme architecture would have defined the verification standard for each corridor before the vendor began operating. It would have specified the evidence standard required for each check type. It would have documented the data handling chain and established a governance cadence for reviewing it. The structural gaps that took three years to accumulate would not have existed, because the structure would have been defined at the outset.
This is not a report. It is a set of documents that define how the programme works, what evidence it produces, who is accountable, and how it is governed. These documents become the specification against which vendor performance is measured.
Role type to verification depth mapping, by corridor, with methodology specifications, source requirements, and evidence standards for each check type. This is the document that answers "what does 'verified' mean in this programme?"
Defines what documentation is produced for each check: who was contacted, what was confirmed, what was not, the method used, the timestamp, and the analyst identity. This is the document an auditor reviews to assess defensibility.
Defines who is responsible for verification quality, exception handling, escalation, and compliance integrity. This is the document that answers "who is accountable when something fails?"
Maps every entity that processes candidate data, the jurisdiction, legal basis, consent mechanism, and retention schedule. This is the document produced when a regulator asks how data moves through the programme.
Defines what is measured, how deviations are identified, what triggers review, and how the architecture is updated as corridors or regulatory requirements change. This is what prevents structural drift.
Translates the programme architecture into a vendor-facing specification. This replaces the generic RFP with a document that tells the vendor exactly what the programme requires, so responses are measured against defined standards.
Without programme architecture, procurement evaluates vendors against each other. With programme architecture, procurement evaluates vendors against a defined specification. The difference is structural.
When the specification is defined, the RFP becomes precise. Vendor responses are measured against documented requirements, not against competing proposals. The evaluation criteria are derived from the programme's needs, not from the vendor's marketing. Pricing is assessed against a defined scope, not against a generic package that varies by vendor interpretation.
Programme architecture also changes the commercial dynamic. The organisation negotiates from a position of specificity: this is what we need, to this standard, with this evidence, in these corridors. The vendor either meets the specification or they do not. The conversation shifts from "what do you offer?" to "does your capability meet our documented requirement?"
Vendors are evaluated on price, turnaround, and country count. The cheapest compliant-looking proposal wins. The programme that results from the selection is shaped by the winning vendor's defaults. Nobody knows whether those defaults are sufficient because sufficiency was never defined.
Vendors are measured against documented requirements for verification depth, evidence standards, data handling, accountability, and governance. The selected vendor is the one that meets the specification. The programme is defined before the vendor is chosen. Sufficiency is documented and measurable.
We operate across 30+ markets. We process verifications in corridors where databases are incomplete, where institutions respond inconsistently, where regulatory requirements shift annually, and where the difference between a defensible verification and a processed one is determined by methodology, not technology.
That operational experience is what programme architecture is built on. It is not a theoretical framework. It is a set of decisions derived from knowing what breaks in practice: where criminal checks fail without physical court access, where employment verification stalls because the institution has no formal HR function, where education records are fabricated at a rate that database-only methods do not detect, where data protection requirements differ from what the DPA assumes.
We do not define programme architecture as a consulting exercise. We define it as operators who will be accountable for the verification outcomes that the architecture produces. The architecture is not a document that sits on a shelf. It is the specification that governs how we operate the programme.
Programme architecture is the structural layer between organisational need and vendor capability. It defines what the programme is supposed to achieve, so every subsequent decision, vendor selection, commercial terms, compliance monitoring, is measured against a documented standard. Without it, those decisions are made in a vacuum.