Security certifications and policies are useful supplier-assurance evidence, but each has a defined scope, date and purpose. ISO/IEC 27001 shows that an information security management system has been assessed within a stated scope; SOC 2 reports examine controls for a defined system and period or date; policies document intended control design. None of these artefacts, on its own, shows the supplier’s current external exposure or how deeply that supplier is connected to your organisation.
For vendor risk and third-party assurance, the useful question is very specific: what exactly was assessed, when was it assessed, and does that scope include the service and relationship you are relying on?
Security certifications and policies provide evidence about defined controls, systems and management practices within a stated scope and time period. They do not establish that every service a supplier provides is covered, that every control is operating today, or that the supplier creates the same level of exposure for every customer.
What are security certifications and security policies?
A security certification is independent assurance that an organisation, management system or defined set of controls has been assessed against specified criteria within a stated scope.
A security policy is an internal statement of how a control or process is intended to work. It can show that responsibilities, rules and expected behaviour have been documented and approved. The policy itself does not show whether the control is operating effectively today.
ISO/IEC 27001, for example, sets requirements for an information security management system (ISMS). Certification provides evidence that the ISMS has been independently assessed for conformity within the certification scope.
What does a security certification certify?
A certification gives assurance against defined criteria and within a defined scope. The organisation seeking certification defines the scope it wants assessed, and an independent certification body evaluates whether the relevant management system or controls meet the scheme requirements.
That scope can be narrower than the organisation as a whole. It may cover particular business units, locations, systems, or services. The certification body is independent, but the organisation seeking certification engages and pays for the assessment. That is a normal feature of conformity assessment, and the reason buyers should read the scope rather than treating the badge as universal assurance. If the service you use sits outside scope, the certification is still useful evidence about the supplier’s wider security management, just not direct assurance for that service.
What is the difference between SOC 2 Type I and Type II?
A SOC 2 Type I report assesses whether controls are suitably designed as of a specified date, while a Type II report also assesses whether those controls operated effectively over a stated period. For vendor due diligence, that time dimension is often more useful than the label alone.
SOC 2 reports address controls at a service organisation relevant to security, availability, processing integrity, confidentiality or privacy. The report still has a defined system description, criteria and scope, so buyers should review what is included, what is carved out, the period covered, and any complementary controls expected from customers or subservice organisations.
The practical reading is simple: Type I answers what was designed at a date; Type II adds evidence about operation across a period.
What does a written security policy prove?
A written security policy proves that the supplier has documented an intended approach to a control or security responsibility. It can show ownership, expected behaviour, review requirements and the control design the organisation says it follows.
That is useful evidence, especially for controls that cannot be observed externally. A policy may explain privileged-access governance, incident escalation, backup requirements or certificate-management expectations. The document alone cannot establish that those practices were followed yesterday, or that every environment is operating in line with the policy.
Where policy and practice can diverge
A supplier can have a documented control and still show external evidence that deserves investigation. Both facts can be true at the same time because policy describes the intended control, while externally observable infrastructure shows part of the current operating state.
ThingsRecon has observed certificate and configuration hygiene issues on third-party infrastructure serving content into customer applications. A supplier policy may describe certificate rotation, configuration standards or patching expectations, while the infrastructure visible from outside provides evidence about what is actually exposed at that moment. The external finding does not invalidate the policy. It gives the customer a specific condition to validate with the supplier.
This is where independent evidence is most useful: it turns a broad assurance statement into a testable question about the systems that are actually connected to you.
Why can a certified supplier still create significant risk?
Certification tells you something about the supplier’s controls within scope; it does not tell you how much exposure that supplier creates for your organisation. Two customers can use the same certified supplier in completely different ways, with different integrations, access paths and operational dependencies.
That relationship-specific context is why Digital Proximity matters. It measures how technically close a supplier sits to your organisation and critical systems. A certification describes assurance about the supplier in a defined scope; proximity adds evidence about what that supplier is to you specifically.
A supplier with strong assurance evidence can still deserve close attention when it is deeply integrated, difficult to replace or connected to critical services. The certification remains useful. The relationship determines how much additional assurance is warranted.
How should security teams use certifications?
Certifications work best as structured evidence inside a broader supplier-assurance process. They can support several practical decisions:
- Screening filter. Use relevant certifications to identify whether a supplier has established baseline security-management practices.
- Scope check. Confirm that the certification scope includes the service, legal entity, location or system relevant to your relationship.
- Contractual hook. Use certification status, evidence access and notification obligations as inputs to contractual assurance where appropriate.
- Renewal trigger. Re-check certification status, scope and supporting evidence at renewal or when the service materially changes.
- Assurance baseline. Use certification as one layer of evidence, then add relationship-specific and current evidence according to inherent risk.
This also keeps the role of questionnaires clear. Vendor questionnaires can collect evidence about controls that are invisible externally, while certifications and audit reports add independent assurance for defined scopes. Each source answers a different question.
What does externally observable evidence add?
External evidence adds a current, independently observable view of the parts of a supplier’s digital environment that are visible from outside. It can help validate whether exposed infrastructure, services and configurations align with the assurance picture provided on paper.
ThingsRecon Supply Chain Intelligence combines EASM with supply-chain and third-party intelligence in an agentless platform. It discovers suppliers that are visibly connected to an organisation, attributes their infrastructure and adds relationship context through Digital Proximity. This external layer does not require agents or supplier questionnaires to collect observable evidence.
That makes it complementary to supplier due diligence: documentation explains controls, scope and intent; external discovery can show current observable conditions and connections that may warrant validation.
Three checks before you rely on any assurance artefact
Before accepting a certification, audit report or policy as evidence, run three checks. They keep the document tied to the relationship you are actually assessing rather than to the supplier in the abstract.
- Scope. Does the evidence cover the legal entity, service, location, system or environment you actually use? A valid certification can still leave the relevant service outside scope.
- Time. What date or period does the evidence describe, and what may have changed since then? A Type I report speaks to a date; a Type II report speaks to a period; a policy speaks to the version that was approved.
- Relationship. What does this supplier do for you specifically? Even strong assurance evidence cannot tell you how deeply the supplier is integrated into your systems, how replaceable it is or what operational dependency exists in your environment.
Those three checks separate documentary assurance from relationship-specific assurance. They also make the comparison table below more useful: every artefact has a purpose, and every artefact has a boundary.
Security certifications and policies: what each artefact proves
The table below is designed as a practical reading guide.
Artefact | What it proves | Limits to check | What external evidence adds |
|---|---|---|---|
| ISO/IEC 27001 certification | An ISMS was independently assessed against ISO/IEC 27001 within a stated scope. | The scope may exclude the service, entity or location you use. Confirm current status and the latest surveillance audit. | Current infrastructure and supplier connections to compare against the certified scope. |
| SOC 2 Type I | Controls for a defined system were suitably designed as of a specific date. | Point-in-time only, with no evidence of operation over a period. Check the as-of date, carve-outs and subservice organisations. | Changes in exposed services or configurations since the report date. |
| SOC 2 Type II | Controls for a defined system were designed and operated effectively over the report period. | Silent on conditions after the period ends. Check exceptions, carve-outs and complementary user-entity controls. | Current observable conditions between report periods. |
| Cyber Essentials / Plus | The scheme’s five technical controls are in place; Plus adds independent technical testing. | A narrow control set that may cover only part of the organisation. Certification expires after 12 months. | Current exposure on the systems actually connected to you. |
| Third-party audit report | Independent findings on the subject matter the engagement explicitly covered. | Nothing outside the engagement scope or after the testing date. Read the objective, exclusions and qualifications. | Independent observation that supports or challenges specific findings. |
| Internal security policy | The supplier has documented and approved how a control is intended to operate. | Not proof the control operates or applies to every environment. Check owner, version and approval date. | Observable configurations to compare against the stated policy. |
The policy-versus-practice check to run this week
Pick one important supplier and one control the supplier has documented. It could be certificate management, exposed-service hygiene, patching expectations, or another condition that leaves externally observable evidence. Then compare the stated control with what can actually be seen from outside.
If the two line up, you have another layer of confidence. If they do not, you have a specific question to take back to the supplier. Either result is more useful than treating the existence of a certification or policy as the end of the assessment.
Mature supplier assurance uses both forms of evidence: certifications and policies explain scope, design and intent; external signals provide current evidence about observable conditions. The quality of the decision comes from understanding what each source can genuinely support.
