Learn how to evaluate supplier security control design, implementation and operating effectiveness, review supporting evidence, identify assurance gaps and document defensible supplier findings. Includes practical examples and a control assessment exercise.
You are working as a GRC analyst at Meridian Financial Services, a fictional UK fintech company.
The organisation wants to onboard a supplier that will host a customer-facing application.
You have already completed the supplier's inherent risk assessment, issued a due diligence questionnaire and received its responses.
The supplier states:
The answers appear satisfactory.
But how do you establish that these controls actually exist and work?
The supplier has submitted an access control policy, a vulnerability management procedure, a backup configuration screenshot and a SOC 2 Type 2 report.
Some documents appear relevant. Others are incomplete or cover different environments.
Your task is to determine which controls are adequately supported by evidence, which require further investigation and which have identifiable weaknesses.
This is a central part of supplier security assurance.
A GRC analyst should not assess controls solely by whether the supplier answered Yes. The assessment must consider what the evidence demonstrates and what remains uncertain.
Supplier security control assessment is the process of evaluating safeguards relevant to risks introduced by a third-party relationship.
Its purpose is to determine whether the available evidence supports conclusions about the controls necessary to protect the organisation's information, systems and business operations.
Examples of controls include:
An assessment should focus on controls relevant to the service being purchased and the risks identified.
For example, if a supplier has privileged access to production infrastructure, access management and activity monitoring are likely to be important assessment areas.
If the supplier provides critical processing services, resilience and recovery arrangements may be equally important.
The objective is not to award a general security score without context.
It is to establish whether the safeguards relevant to specific risks are sufficiently designed, implemented and operating, based on the evidence available.
These are three related but distinct concepts.
Control design concerns whether a proposed safeguard is structured appropriately to address its intended risk.
Suppose a supplier's privileged access procedure requires:
This may indicate a reasonable control design.
However, a documented procedure does not establish that the requirements are actually implemented.
Implementation concerns whether the control has been put into place for the relevant systems, people or processes.
For example, the supplier may provide configuration evidence showing MFA enforcement for privileged production accounts.
This may support implementation.
However, a point-in-time configuration extract does not necessarily establish that MFA operated effectively throughout the period being assessed.
Operating effectiveness concerns whether a control performs as intended over a defined period or across relevant events.
For example, a supplier may provide dated quarterly privileged access reviews showing that the required accounts were reviewed, exceptions were identified and resulting actions were completed.
This evidence may support operating effectiveness, subject to its coverage and quality.
| Assessment area | Main question | Example evidence |
|---|---|---|
| Design | Is the control structured to address the intended risk? | Approved control procedure |
| Implementation | Has the control been deployed in the relevant environment? | Configuration or implementation evidence |
| Operating effectiveness | Has the control functioned as required over the relevant period? | Dated review records, test results or operating evidence |
A control can be well designed but poorly implemented.
It can also be implemented but fail to operate consistently.
A defensible assessment should distinguish these situations.
Before reviewing evidence, establish what the supplier is expected to demonstrate.
Consider the following requirement:
Privileged access to the production hosting environment must be restricted to authorised users and protected by approved authentication controls.
This requirement is more useful than a vague statement such as:
The supplier must have strong security.
The analyst can now identify the evidence needed to assess the requirement.
For example:
Consider the following example.
| Supplier risk | Relevant control | Assessment objective |
|---|---|---|
| Unauthorised production access | Privileged access management | Determine whether administrative access is appropriately restricted |
| Disclosure of customer information | Information protection | Determine whether relevant information is appropriately safeguarded |
| Exploitation of known vulnerabilities | Vulnerability management | Determine whether relevant vulnerabilities are identified and managed |
| Prolonged service disruption | Backup and recovery | Determine whether the supplier can restore required services |
| Delayed incident detection | Security monitoring | Determine whether relevant events are detected and investigated |
This risk-to-control mapping should guide which evidence is requested and how the results are interpreted.
A useful evidence assessment examines five characteristics.
Does the evidence relate to the control requirement?
For example, a password policy does not necessarily demonstrate that MFA is enforced.
A vulnerability management policy does not automatically demonstrate that critical vulnerabilities are remediated within the required timeframe.
Does the evidence cover the correct service, systems, users and environment?
A supplier may provide MFA configuration evidence from a staging environment when the requirement concerns production access.
The evidence may be authentic, but its scope is insufficient for the control being assessed.
Is the evidence sufficiently recent for the purpose of the assessment?
A recovery test completed several years ago may provide limited assurance about a service that has since undergone significant changes.
Currency should be considered alongside control frequency, service changes and organisational requirements.
How was the evidence produced, and how much confidence can reasonably be placed in it?
For example:
No evidence format should be treated as universally conclusive.
A relevant internal technical record may be more useful for a specific question than an independent report that excludes the relevant service.
Is there enough evidence to support the assessment conclusion?
A screenshot showing one MFA-enabled account may not establish that all relevant privileged accounts are covered.
The analyst should consider the applicable population, timeframe, exceptions and assurance requirements.
Evidence is sufficient when it supports the specific conclusion being made, not merely because a document has been provided.
A structured review can follow seven steps.
Determine the expected safeguard and the risk it addresses.
Specify what would demonstrate satisfactory design, implementation or operation.
For MFA, this may include confirmation of coverage for relevant privileged accounts and handling of exceptions.
Determine which documents, records, technical demonstrations or independent assurance sources could support the requirement.
Assess relevance, scope, currency, reliability and sufficiency.
State what is supported, what is unsupported and what remains uncertain.
Seek additional evidence or corrective action where necessary.
Confirm whether the issue has been resolved and update the assessment records.
These activities may involve GRC, technical security specialists and the supplier relationship owner.
The GRC analyst should not claim to have technically verified a control that was not actually tested or demonstrated.
This is one of the most important distinctions in supplier assurance.
An evidence gap exists when the information available is insufficient to verify a relevant requirement.
Example:
The supplier states that MFA is enabled but provides only its access control policy.
Conclusion: MFA enforcement for the relevant accounts has not yet been demonstrated.
This does not establish that MFA is absent.
A confirmed weakness exists when the available evidence demonstrates that a required safeguard is absent, inadequately designed, improperly implemented or operating ineffectively.
Example:
The supplier confirms that several privileged production accounts do not have MFA enabled, contrary to the applicable requirement, and provides a configuration extract supporting that position.
Conclusion: A relevant control deficiency has been identified.
A control exception is a departure from an applicable control requirement or expected operation identified during a review or test.
Example:
A quarterly access review was completed after the defined deadline.
The exception should be evaluated for context, impact, cause and recurrence.
A control may not apply to the assessed relationship.
Example:
A question concerns development of customer-facing software, but the supplier provides an unrelated service with no software development responsibility relevant to the engagement.
The analyst should verify the justification rather than automatically accept the supplier's response.
| Assessment outcome | Meaning | Appropriate response |
|---|---|---|
| Supported | Evidence adequately supports the assessed requirement | Record conclusion and limitations |
| Partially supported | Only part of the requirement is supported | Clarify the uncovered elements |
| Evidence insufficient | The control cannot yet be adequately verified | Request appropriate further evidence |
| Confirmed weakness | Evidence demonstrates a relevant control deficiency | Document and assess the finding |
| Exception identified | A deviation from expected operation has been identified | Determine significance and remediation |
| Not applicable | Requirement does not apply with documented justification | Record and validate rationale |
These are suggested GRC Workshop assessment statuses. They are not universal certification or audit classifications.
Meridian Financial Services is reviewing CloudCore Infrastructure, a fictional supplier hosting its production customer platform.
The supplier has submitted responses to its security questionnaire.
Requirement: MFA must protect relevant privileged production accounts.
Supplier response: Yes.
Evidence: An approved access control policy requiring MFA and a screenshot of a staging administrator account.
Analysis: The policy supports design intent. The staging screenshot does not demonstrate production coverage.
Conclusion: Evidence insufficient.
Follow-up: Request appropriately scoped evidence of MFA enforcement for relevant production accounts, including treatment of exceptions.
Requirement: Relevant vulnerabilities must be identified, prioritised and remediated or managed through approved exceptions.
Supplier response: Yes.
Evidence: Vulnerability management policy and a recent remediation report covering production infrastructure.
Analysis: The policy supports design. The remediation report provides operating evidence, but one overdue critical finding requires explanation.
Conclusion: Partially supported; potential control exception requires review.
Follow-up: Confirm the finding's affected systems, risk, remediation status and any approved exception.
Requirement: Relevant production data must be backed up and restoration arrangements tested according to approved recovery requirements.
Supplier response: Yes.
Evidence: Backup configuration and a recent successful restoration test for the purchased service.
Analysis: The evidence supports implementation and a successful restoration test within the stated scope.
Conclusion: Supported for the evidence examined, subject to confirming that the test adequately covered the organisation's recovery requirements.
Follow-up: Compare tested recovery performance with agreed recovery objectives.
Requirement: Material incidents affecting the purchased service must be investigated and escalated according to the agreed process.
Supplier response: Yes.
Evidence: Incident response procedure and a sanitised exercise summary.
Analysis: The documentation supports process design. The exercise provides evidence of testing, but the extent of operational performance demonstrated depends on the exercise scope.
Conclusion: Supported for documented process design and the exercise performed; broader effectiveness may require additional assurance.
Follow-up: Confirm applicable notification arrangements and whether significant issues from the exercise remain unresolved.
Requirement: Privileged access must be reviewed quarterly.
Supplier response: Yes.
Evidence: Dated quarterly access review records identifying a review that was completed after the required deadline.
Analysis: Reviews took place, but one documented deviation occurred.
Conclusion: Control exception identified.
Follow-up: Establish the cause, affected accounts, duration of delay, corrective action and relevance to the relationship.
| Control | Assessment | Main concern |
|---|---|---|
| Privileged MFA | Evidence insufficient | Production coverage unverified |
| Vulnerability management | Partially supported | Overdue critical finding |
| Backup and recovery | Supported within reviewed scope | Recovery objective confirmation |
| Incident response | Supported with limitations | Extent of operational assurance |
| Access reviews | Exception identified | Late review and remediation |
Notice that the findings are not all equivalent.
The MFA issue is primarily an assurance gap.
The vulnerability management issue may represent a control deficiency depending on further evidence.
The access review issue is a documented exception.
These distinctions are important when the organisation later evaluates residual risk.
An evidence gap finding should describe what has not been demonstrated without claiming more than the evidence supports.
Finding ID: EV-001
Supplier: CloudCore Infrastructure
Control area: Identity and access management
Requirement: MFA must protect relevant privileged access to the production hosting service.
Supplier claim: MFA is enforced for privileged users.
Evidence reviewed: Access control policy and staging environment configuration screenshot.
Observation: The supplied evidence does not establish MFA enforcement for the relevant production privileged-account population.
Finding type: Evidence insufficient.
Potential exposure: The organisation cannot currently determine whether privileged production access is protected in accordance with its requirement.
Required action: Provide appropriate production-specific evidence or an acceptable alternative assurance method.
Internal owner: Supplier relationship owner, supported by Information Security and GRC.
Status: Open, awaiting evidence.
This wording is objective.
It avoids claiming that MFA is absent when the available information only establishes that enforcement has not been verified.
Suppose the supplier subsequently confirms that several privileged production accounts do not enforce MFA.
Relevant technical evidence supports the admission.
The finding can now be updated.
Finding ID: CT-001
Control area: Privileged access management
Requirement: Relevant privileged production access must be protected by approved MFA controls.
Observation: Three in-scope privileged production accounts do not enforce MFA, contrary to the applicable requirement.
Evidence: Supplier-confirmed configuration records reviewed by the security team.
Potential exposure: Compromise of an affected account could allow unauthorised privileged activity without the additional authentication factor required by the organisation.
Required action: Remediate the affected accounts, investigate whether compensating controls are necessary, and provide verification evidence.
Status: Open, remediation required.
The finding should then be assessed for its potential impact on the relevant supplier risk scenarios.
A confirmed deficiency does not automatically require rejecting the supplier.
The appropriate action depends on the exposure, required treatment, available alternatives and applicable governance authority.
Exceptions should be reviewed in context.
For each material exception, consider:
For example, a single delayed access review may be less significant than repeated failures affecting privileged accounts on critical systems.
However, that conclusion must be supported by the context and evidence.
Do not assign severity solely from the number of exceptions.
Operating effectiveness requires evidence that a control performed as intended over the relevant period or when required events occurred.
The requirement states that privileged access must be reviewed quarterly.
The supplier provides one completed review from the current quarter.
Does this prove that reviews operated effectively for the preceding year?
No.
It may demonstrate that a review occurred during the current quarter.
To assess operation over the previous year, the analyst would need evidence appropriate to the period and requirement.
This may include:
The appropriate depth of testing depends on the supplier's risk, the assessment objective and the organisation's methodology.
Where sample-based testing is used, consider whether the samples represent the relevant population and timeframe.
A sample of standard user accounts may not provide sufficient assurance about privileged accounts.
Similarly, samples from a test environment may not demonstrate production controls.
The analyst should record the extent of testing and avoid generalising beyond what the evidence supports.
Suppliers may be reluctant to share sensitive information, including:
The organisation should request proportionate evidence.
Possible alternatives include:
These alternatives may provide useful assurance while protecting sensitive supplier information.
If none is sufficient, document the limitation and determine whether the unresolved uncertainty is acceptable under the organisation's governance process.
A supplier's unwillingness to disclose a sensitive document is not necessarily a control failure, but the organisation must still decide whether it has sufficient assurance to proceed.
Some TPRM programmes assign control effectiveness ratings.
For example:
| Rating | Illustrative definition |
|---|---|
| Effective | Sufficient evidence supports the required control design and operation within scope |
| Partially effective | Relevant aspects are supported but material limitations or deficiencies remain |
| Ineffective | Evidence establishes that the control does not adequately meet its requirement |
| Not assessed | Evidence or review work is insufficient to reach an effectiveness conclusion |
| Not applicable | The control is outside the assessed requirement, with documented justification |
These labels can help summarise results.
However, assessment status and control effectiveness should remain distinguishable.
For example, evidence insufficient is not the same conclusion as ineffective.
An organisation may choose to treat uncertainty conservatively in decision-making, but should not relabel unverified effectiveness as a confirmed technical failure.
Only where a documented methodology supports it.
A simple average can be misleading.
A supplier might score highly across many low-impact controls while failing an important privileged access requirement.
The programme should consider material control deficiencies, risk dependencies, evidence confidence and mandatory requirements.
An aggregate score should support judgement, not replace it.
The inherent supplier risk assessment identified what could go wrong before considering relevant controls.
The control assessment examines the safeguards that may reduce those exposures.
Consider the inherent risk scenario:
Compromise of privileged hosting access could result in unauthorised changes to production systems and significant customer service disruption.
Relevant controls may include:
If evidence supports the design and effective operation of these controls, the organisation may conclude that some likelihood or consequence assumptions should be revised.
If material controls are ineffective or insufficiently verified, the residual assessment must reflect that fact or uncertainty.
For example, an inherent risk score of 20 should not automatically become 10 simply because five security controls are documented.
The effect of each relevant control must be evaluated according to the organisation's risk methodology.
Also distinguish:
A promised remediation does not automatically reduce the current residual risk.
The next lesson will explore the relationship between findings, residual exposure and risk treatment decisions in detail.
A remediation action should have:
Finding: Privileged production accounts lack required MFA.
Action: Implement MFA for all relevant privileged production accounts or obtain approval for an appropriately assessed exception.
Owner: Supplier Security Manager.
Target date: Agreed through the supplier management process.
Required evidence: Suitable configuration or independent assurance confirming the relevant account coverage.
Verification: Information Security reviews the evidence and confirms whether the requirement has been met.
Closure: GRC updates the record following the required verification and approval process.
A supplier's statement that remediation is complete is useful information, but it may not be sufficient for formal closure.
The level of verification should reflect the importance of the finding.
A management summary should communicate the significant issues rather than repeat every questionnaire answer.
CloudCore Infrastructure has provided evidence supporting several relevant security controls, including backup restoration and incident response arrangements. However, assurance remains incomplete for privileged production MFA, and the vulnerability management and access review evidence requires follow-up. These issues should be addressed before the control assessment is considered complete. The GRC and security teams should evaluate their significance for residual supplier risk and provide recommendations to the designated business risk owner.
This summary identifies:
It does not make an unsupported claim that the supplier is secure or insecure.
You are a junior GRC analyst at Meridian Financial Services.
The organisation is reviewing SupportBridge, a fictional SaaS customer-support supplier.
SupportBridge processes customer information and connects to the internal customer management system.
The supplier provides the following evidence:
An approved policy requires MFA for privileged accounts.
No production configuration evidence is provided.
A recent report identifies 14 vulnerabilities.
Twelve are recorded as remediated.
Two remain open, including one classified as critical.
The report does not include approved exception records.
A dated recovery test shows a successful restoration of the customer support database.
The stated recovery time is four hours, but the business owner's recovery requirement has not yet been confirmed.
A sanitised exercise report describes a completed incident simulation.
The report identifies two improvement actions, one of which remains outstanding.
The supplier provides three completed quarterly reviews from the previous year.
One expected quarterly review is missing.
Prepare a control assessment table covering:
Then prepare a short management summary explaining which matters need resolution before the supplier assessment can proceed.
| Control | Initial conclusion | Required follow-up |
|---|---|---|
| Privileged MFA | Evidence insufficient | Verify production implementation and coverage |
| Vulnerability management | Potential control weakness; further evaluation required | Assess the critical vulnerability, remediation criteria and exceptions |
| Backup and recovery | Restoration evidenced, but suitability not fully established | Confirm business recovery requirements and test coverage |
| Incident response | Exercise performed with outstanding action | Evaluate unresolved improvement and operational significance |
| Access reviews | Evidence gap or potential missed review | Confirm whether the missing review was performed and assess any failure |
SupportBridge has provided useful evidence for several security controls, but the assessment remains incomplete. Privileged MFA enforcement has not been demonstrated for production accounts. The vulnerability report contains an unresolved critical finding requiring risk and remediation review. Backup restoration has been demonstrated, although compliance with business recovery requirements is not yet confirmed. Additional clarification is also required concerning incident exercise actions and the missing quarterly access review. The business owner should coordinate outstanding evidence with the supplier, while GRC and Information Security assess material findings before recommending a residual risk position.
| Criterion | Marks |
|---|---|
| Correct classification of evidence and control status | 25 |
| Evaluation of evidence relevance and sufficiency | 25 |
| Identification of material issues and uncertainty | 20 |
| Appropriate follow-up and verification actions | 15 |
| Clear management summary and ownership | 15 |
| Total | 100 |
This exercise is designed for self-assessment. Other conclusions may be acceptable where the learner provides sound reasoning and stays within the available evidence.
Policies establish expectations and may support design, but do not automatically prove operation.
Evidence must match the control, service and environment under review.
The former creates uncertainty; the latter requires facts demonstrating a deficiency.
A single screenshot may not demonstrate performance across all relevant accounts or over time.
A score needs defensible criteria and supporting evidence.
An unmodified assurance opinion does not make all exceptions irrelevant.
Corrective actions should be evidenced and checked according to their significance.
Current risk should reflect present controls, not assumed future improvements.
GRC should provide clear findings and recommendations while preserving the organisation's defined risk ownership and approval arrangements.
Before finalising a supplier control assessment, confirm:
Supplier control assessments help organisations determine whether relevant safeguards are adequately supported by evidence.
A well-designed control may not be implemented, and an implemented control may not operate consistently.
GRC analysts should evaluate evidence for relevance, scope, currency, reliability and sufficiency.
Evidence gaps, control weaknesses and exceptions should be documented separately.
Control assessment findings must be connected to the risks the controls are intended to address.
Remediation should be verified before findings are closed, and future control improvements should not automatically reduce current residual risk.
A good control assessment is not a collection of Yes or No answers. It is a documented, evidence-based explanation of what is working, what is not, and what still needs to be established.
Next lesson: Supplier Risk Findings, Residual Risk and Treatment Decisions
You have learned how to evaluate supplier security controls and distinguish evidence gaps from confirmed weaknesses.
The next guide will show how to use these findings to reassess risk exposure, recommend remediation, escalate material issues and support appropriate risk treatment or acceptance decisions.