Evidence vs Attestation

A cloud platform vendor received a TPRM questionnaire asking about encryption at rest for customer data. Their CISO completed the questionnaire with confidence: all customer data is encrypted at rest using AES-256. This was the organisation's standard and had been consistently applied across their infrastructure. What the CISO did not know was that six months prior, a database had been provisioned by a new infrastructure engineer for a customer-specific analytics workload. The engineer had selected the default settings in the cloud console, which enabled encryption but used the cloud provider's default key management rather than the organisation's customer-managed key (CMK) configuration that the standard required. The difference was not AES-256 versus an alternative cipher , the cloud default was also AES-256. The difference was in key management: the CMK configuration provided the organisation with control over key rotation and key access; the default configuration left key management with the cloud provider. The attestation , 'all data is encrypted at rest with AES-256' , was accurate. The implication , that all encryption was implemented per the organisation's standard with customer-managed keys , was not accurate for one database. The CISO's attestation reflected their genuine belief. It did not reflect the actual configuration of all relevant systems.

What is the Evidence vs Attestation Problem, Really?

Attestation is a statement made by an authorised individual asserting that a condition is true , typically based on their knowledge, belief, or understanding of the organisation's policies, standards, and practices. Evidence is the documentation, configuration records, system outputs, and artefacts that demonstrate, independently of the attester's belief, that a condition is true. The difference between the two is the difference between what someone believes to be true about their organisation and what is verifiably true about specific systems, configurations, and practices.

Attestations are accurate when the attester has complete and current knowledge of all relevant systems and configurations. In simple, small organisations, attestations can be highly accurate. In complex, distributed organisations with multiple infrastructure teams, frequent deployments, and decentralised configuration management, attestations are accurate for the attester's knowledge domain but may not reflect the configuration reality of systems outside that domain or provisioned recently by different teams. The CISO's attestation that all data is encrypted per standard reflects their knowledge of the organisation's standard and their belief that all systems comply with it , not the actual configuration records of each individual system.

The configuration drift problem is the most common source of attestation-reality gaps. Standards are established and communicated. Individual system provisioning follows , or fails to follow , those standards at the time of provisioning. As teams grow, as provisioning velocity increases, and as cloud environments expand, the gap between the standard as attested and the individual configurations as actually deployed grows. An attestation made when the organisation had twenty databases and three infrastructure engineers accurately described the known configuration. The same attestation made two years later with sixty databases and fifteen engineers , some of whom were hired after the standard was established and may not have received adequate training on its specifics , may accurately describe the standard but not the full configuration landscape.

• Attestation reflecting intended standard rather than actual configuration , CISO confirming organisation's encryption standard rather than each system's actual encryption configuration
• Configuration drift between standard and individual system implementations , recent provisioning not following standard due to default settings, training gaps, or oversight
• Attester knowledge gap , senior staff attestation not reflecting configurations managed by different teams
• No independent configuration verification , accepting attestation without technical validation of actual system configurations
• Attestation scope ambiguity , whether attestation covers all relevant systems or the attester's known systems

Why this matters

Evidence versus attestation matters for TPRM because the security risk created by a vendor relationship is determined by the actual configuration of the systems handling customer data , not by the organisation's standard or the CISO's belief about compliance with that standard. A vendor whose standard requires AES-256 with CMK but has one database using default provider key management presents a different risk than a vendor with the same standard and full compliance. The attestation confirms the standard. The evidence reveals the compliance rate.

The regulatory dimension is explicit. GDPR's accountability principle requires that data protection is demonstrable , not attested. An organisation that can attest to its encryption standard but cannot demonstrate that every relevant system implements that standard has met the attestation requirement and not the evidence requirement. Regulators who examine evidence rather than accepting attestation will find the database configured with default key management , and the attestation that was accurate for two-thirds of the systems will not satisfy the examination for the one-third that was different.

Where most teams get this wrong

The most consistent failure is accepting attestations from senior security or compliance staff as evidence of system configuration rather than as statements of organisational standards and beliefs. CISO attestations are valuable as confirmations of policy and standards. They are not technical evidence of system configuration. The two require different types of documentation to verify.

• Accepting senior staff attestation as configuration evidence
• No technical evidence requests , configuration records not requested for specific systems
• Attestation scope not clarified , whether it covers all relevant systems or the attester's knowledge
• Configuration drift not assessed , whether recently provisioned systems comply with stated standard
• Evidence verification gap , accepting attestation without independent verification

What good looks like

Mature evidence programmes request technical configuration evidence for the specific systems relevant to the customer relationship , not attestations from senior staff, but configuration records, tool outputs, and system-level verification for each system handling customer data.

• System-specific configuration evidence , encryption configuration for each database or storage system holding customer data
• Technical tool output , CSPM scan results, configuration management records, or compliance monitoring output rather than staff attestation
• Coverage verification , confirmation of which specific systems were assessed in the attestation
• Recent provisioning review , whether systems provisioned in the last six to twelve months have been verified against the stated standard
• Exceptions documentation , any systems that are exceptions to the stated standard and why

Tooling

Configuration Evidence , AWS Config, Azure Policy, GCP Security Command Center

Cloud configuration management tools produce technical evidence of resource configuration , encryption settings, key management configurations, and security policy compliance , that serves as configuration evidence independent of staff attestation. For TPRM practitioners, asking whether vendors can provide cloud configuration compliance reports from their CSPM or cloud configuration management tools provides a request for technical evidence rather than attestation.

Automated Compliance , Drata, Vanta

Automated compliance platforms collect configuration evidence continuously and can produce system-level compliance reports showing which specific systems comply with defined controls and which do not , directly surfacing the configuration drift that makes attestations inaccurate. For TPRM practitioners, asking for an automated compliance report rather than a questionnaire response provides the technical evidence that attestation cannot.

Governance challenges

The governance challenge with evidence versus attestation is the effort disparity. Attestations are easy to produce , a senior staff member confirms their belief. Technical configuration evidence requires querying systems, generating reports, and reviewing actual configuration records. The effort differential creates pressure toward accepting attestations as more efficient. The risk differential makes accepting attestations without technical evidence a governance gap.

• Request technical configuration evidence rather than accepting staff attestation
• Specify systems in evidence requests , which databases, storage accounts, and systems holding customer data
• Request recent provisioning verification , have systems provisioned in the last year been verified against the stated standard
• Ask about exceptions , any systems that do not comply with the stated standard
• Request CSPM or compliance tool output rather than manual configuration documentation

If you are a small team

For every attestation in your highest-risk vendor assessments, add one follow-up question that converts the attestation to an evidence request: 'For the statement that all customer data is encrypted at rest with AES-256 , can you provide the configuration records or CSPM output confirming that each specific system holding our data implements this configuration, and specifically whether any systems provisioned in the last twelve months have been verified?' That follow-up converts the attestation from a statement of standard to a statement of implementation.

• Follow up on all high-risk attestations with system-specific configuration evidence requests
• Ask specifically about recently provisioned systems , where configuration drift is most common
• Request CSPM or compliance tool output rather than manual attestation
• Ask about exceptions , systems not complying with the stated standard

What to require

Ask directly:

"For the statement that all customer data is encrypted at rest with AES-256 using customer-managed keys , can you provide configuration records or CSPM output for each specific database or storage system holding our data, confirming the encryption configuration of each?"

"Have any storage systems or databases been provisioned in the last twelve months that hold our data , and have those systems been specifically verified against your encryption standard rather than relying on cloud default settings?"

Expect as evidence

• System-level encryption configuration records or CSPM output
• List of all systems holding customer data with their encryption configuration
• Recent provisioning verification confirmation
• Exceptions documentation , any systems not matching stated standard

A vendor whose CISO attests to AES-256 encryption for all customer data should be asked to provide the configuration record for each specific database holding the customer's data. The attestation reflects the standard. The configuration records reflect the reality. When they differ for one system, the evidence reveals what the attestation cannot.

How to evidence it

• Technical configuration evidence records for key vendor controls
• System-specific evidence rather than senior staff attestation
• Recent provisioning verification records
• CSPM output records for technical controls

Key Takeaway

Attestation describes what the attester believes. Evidence describes what is. The CISO's belief that all systems are encrypted per standard is a reflection of the standard and the CISO's knowledge. The actual configuration of a database provisioned six months ago by a different engineer using default settings is a fact about that specific system. Belief and fact diverge when complexity, velocity, and distributed responsibility mean that not every provisioning event is verified against the standard by someone who knows what the standard requires. Request evidence for specific systems. Accept attestation as a statement of standard, not as proof of universal compliance. The one system that is different from the other two is the system that reveals the gap between the attested standard and the actual configuration.

More on Compliance

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