Contractual vs Actual Controls

A retail bank had a comprehensive vendor contract with their payment processing partner , a contract that had been developed by the legal team with significant security input. The contract included specific security requirements: MFA for all access to payment data environments, annual penetration testing, encryption of data in transit and at rest, and incident notification within twenty-four hours. The contract also included a right-to-audit clause permitting the bank to verify compliance with these requirements. In three years of the relationship, the right-to-audit had never been exercised. The security questionnaire sent annually asked the vendor to confirm compliance with contractual requirements, and the vendor confirmed annually. During an incident investigation following a payment fraud event, forensic analysis found that the vendor's support engineers had been accessing the payment environment through a legacy VPN pathway that did not enforce MFA , the MFA requirement applied to the primary access path and had a documented exception for the legacy VPN pending migration. The contract required MFA. The exception existed. The exception was known to the vendor's security team. It had been confirmed annually as 'MFA enforced' on the questionnaire because the primary path had MFA. The contractual requirement was not being met for all access. The questionnaire confirmation was accurate for the primary path. The right-to-audit had never been used to verify the complete picture.

What is the Contractual vs Actual Controls Problem, Really?

Contractual security requirements define the security posture that a vendor must maintain as a condition of the business relationship. They establish obligations, define standards, and create legal recourse if standards are not met. They do not guarantee that the required controls are implemented, operating effectively, or consistently applied across all relevant systems and access pathways. The gap between contractual requirement and actual control implementation is the space between what the organisation has required and what the vendor has delivered , a gap that is invisible without verification.

The verification gap is the operational mechanism that allows contractual requirement gaps to persist. Most vendor contracts include right-to-audit clauses that permit the customer to verify compliance with contractual security requirements. Most customers rarely or never exercise these rights , partly because audit exercises require significant coordination and resource investment, partly because the business relationship creates reluctance to appear adversarial, and partly because annual questionnaire confirmations provide the appearance of verification without requiring it. The right-to-audit that has never been exercised is a verification capability that has never been deployed.

The questionnaire confirmation problem is the specific mechanism through which contractual gaps remain invisible. Annual questionnaires that ask vendors to confirm compliance with contractual requirements receive vendor-provided answers that describe the vendor's understanding of their compliance. These answers may be accurate, inaccurate, or technically accurate but misleading , confirming compliance with the stated requirement as applied to the primary pathway while not disclosing exceptions, legacy system gaps, or narrow interpretations of requirement language. The questionnaire produces a confirmation. It does not produce verification.

• Right-to-audit never exercised , contractual verification right available but not deployed
• Annual questionnaire accepted as verification , vendor self-confirmation accepted as evidence of compliance
• Exception gaps not disclosed , known exceptions to contractual requirements not surfaced in annual confirmations
• Technical requirement interpretation gaps , vendor interpreting requirements narrowly to cover primary pathways while maintaining exceptions on secondary pathways
• No verification methodology for contractual requirements , contracts with requirements but no process for confirming operational compliance

Why this matters

Contractual versus actual controls matters for TPRM because regulatory frameworks increasingly expect that organisations not only have security requirements in vendor contracts but can demonstrate that those requirements are being met. The OCC's third-party risk guidance specifically notes that ongoing monitoring should include verifying that third parties are meeting contractual obligations , not just confirming that contracts contain appropriate requirements. A programme that has strong contractual requirements but no verification mechanism has requirements without assurance.

The incident investigation dimension is equally direct. When a breach occurs through a control gap that was contractually required to be in place, the incident investigation will ask why the contractual requirement was not verified. The right-to-audit clause in the contract provides the verification mechanism. The failure to exercise it is a governance gap that both the organisation's regulators and the organisation's own board will identify. The contract required the control. The control was not present. The verification that would have detected the gap was not performed.

Where most teams get this wrong

The most consistent failure is treating contractual requirements as a substitute for control verification. Requirements specify what must be done. Verification confirms it was done. Both are necessary. Neither substitutes for the other.

• Treating contractual requirements as control verification
• Right-to-audit never exercised for critical contractual requirements
• Annual questionnaire as verification rather than self-confirmation
• No verification programme for highest-risk contractual requirements
• Exception disclosure not required in annual confirmations

What good looks like

Mature contractual control verification programmes exercise the right-to-audit for critical contractual requirements on a defined schedule, require vendors to disclose exceptions to contractual requirements, and design annual questionnaires to surface gaps rather than collect confirmations.

• Exercise right-to-audit for critical requirements on a defined schedule , not just as a right but as a programme
• Require exception disclosure , annual confirmation must include disclosure of any known exceptions to contractual requirements
• Technical verification for highest-risk requirements , testing actual configurations rather than accepting questionnaire responses
• Contract language specifying disclosure obligations , not just compliance requirements but disclosure of exceptions
• Vendor audit programme aligned to contract , verification methodology designed around contractual requirements

Tooling

Vendor Audit Programmes , ISACA audit frameworks, SSAE 18 SOC engagements

Structured vendor audit programmes provide the methodology for exercising right-to-audit clauses effectively , defining what evidence is requested, which controls are tested, and how findings are assessed. For TPRM practitioners, developing a lightweight audit programme for critical contractual requirements provides the verification structure that right-to-audit exercises require.

Technical Verification , penetration testing, configuration assessment, access control testing

Technical verification of specific contractual requirements , MFA enforcement testing, encryption configuration verification, access control scope testing , provides evidence independent of vendor self-reporting. For TPRM practitioners, including technical testing of the highest-risk contractual requirements as part of the right-to-audit exercise provides verification that questionnaire responses cannot.

Governance challenges

The governance challenge with contractual control verification is the resource and relationship tension. Exercising right-to-audit is resource-intensive and can create relationship friction. The governance resolution is risk-tiered audit scheduling , comprehensive right-to-audit exercises for Tier 1 vendors on a defined cycle, targeted verification of specific high-risk requirements for Tier 2, and questionnaire-plus-exception-disclosure for lower tiers.

• Exercise right-to-audit for Tier 1 vendors on a defined cycle
• Require exception disclosure in annual confirmations , known gaps from contractual requirements must be disclosed
• Target verification at highest-risk contractual requirements , MFA, encryption, access controls
• Include technical testing in right-to-audit exercises for critical requirements
• Track verification history , which requirements have been technically verified and when

If you are a small team

Pick the three contractual security requirements you consider most critical for your highest-risk vendor , the requirements where a gap would most directly affect your risk exposure. Then ask the vendor, for each of those three: can you provide the technical evidence confirming the requirement is being met , not a confirmation that the requirement is in your policy, but the configuration or log evidence showing the requirement is technically enforced? That evidence request is a lightweight right-to-audit exercise that does not require a formal audit programme.

• Identify three most critical contractual security requirements
• Request technical evidence of compliance , not questionnaire confirmation
• Require exception disclosure as part of annual confirmation process
• Schedule right-to-audit exercise for highest-risk vendor in next twelve months

What to require

Ask directly:

"For the contractual requirement that [specific requirement, e.g. MFA for all access to our data environment] , can you provide the technical configuration evidence confirming this requirement is enforced, and are there any known exceptions or legacy pathways where this requirement is not currently applied?"

Expect as evidence

• Technical configuration evidence for specific contractual requirements
• Exception disclosure , known gaps from contractual requirements
• Legacy pathway assessment against contractual requirements
• Remediation plan for any disclosed exceptions

A vendor who confirms annual compliance with contractual requirements should be asked for technical evidence of the three most critical requirements and whether any exceptions exist. The confirmation describes what the vendor believes. The evidence describes what the configuration enforces.

How to evidence it

• Right-to-audit exercise records for critical contractual requirements
• Technical evidence collected for highest-risk requirements
• Exception disclosure records
• Verification programme documentation

Key Takeaway

The contract required MFA. The requirement was confirmed annually. The legacy VPN pathway without MFA existed for two years, was known to the vendor's security team, was documented as an exception pending migration, and was never disclosed in an annual confirmation. The right-to-audit clause existed for two years and was never exercised. The contractual requirement specified the standard. The verification gap allowed the standard to be partially met while annually confirmed as fully met. Contractual requirements are requirements. Verification is the governance that confirms they are met. Exercise the right-to-audit. Require exception disclosure. Test technically what matters most. The contract is the specification. The verification is the confirmation.

More on Compliance

• Assurance vs Validation
• Audit Evidence Quality
• Audit Scope Limitations