What A.5.19 asks you to run before any supplier gets access
A.5.19 requires you to define and implement processes for managing the information security risks that come with using suppliers' products and services. It is the policy layer that the agreement controls (A.5.20), the ICT supply chain controls (A.5.21) and the monitoring controls (A.5.22) build on. If an auditor asks how suppliers are controlled, this is the control they expect you to point to first, and they will check that the process exists in writing, that it is applied to real suppliers and that its outputs feed the controls that follow. The risk is straightforward: a supplier that hosts, processes, administers or can reach your information becomes part of your attack surface and your compliance exposure, even though you do not operate its systems. In the 2013 edition the same idea sat under A.15.1.1, Information security policy for supplier relationships. The 2022 revision carried it forward into the organizational controls theme, so an organization certified under the older version should check that its supplier process was mapped to the new control rather than assumed to carry over.
The hard part is usually not writing the procedure. It is deciding what counts as a supplier that needs scrutiny. Most organizations start with a list of paid vendors, then discover that cloud platforms, software libraries, managed service providers, contractors with administrator access and consultants holding customer data all create the same kind of risk in different forms. Before any supplier gets access, decide your supplier categories by the sensitivity of the information and the access involved, then set the due diligence depth for each category, such as a short questionnaire for low-risk tools and evidence reviews for suppliers that handle personal or regulated data. Record who approves each category decision and who owns each supplier relationship, because an auditor will sample that record against your supplier register.
ISO/IEC 27002:2022 gives the implementation guidance for A.5.19, and it is the right document to read alongside the standard when you design the procedure. Confirm your own supplier categories, due diligence criteria and approval roles with your certification body's expectations and your legal team before you finalize them, because regulated sectors may add requirements. A practical first step is to list every supplier with access to your information systems or data, assign each one to a category and record the due diligence evidence you already hold. The gaps you find at that stage will show what the agreement and monitoring controls must cover.
Which suppliers and services fall inside A.5.19
A.5.19 applies to every supplier whose products or services touch information within the ISMS scope, so the first decision is where that scope ends. The cards below cover the supplier types that most often need to be placed on the register, and the checks that show whether each one belongs inside the scope.
SaaS and cloud providers
Software-as-a-service tools and cloud platforms that store, process or transmit in-scope information are the most common entries on the list. Include the tools that staff use directly, such as collaboration, ticketing and code hosting, not only the infrastructure your team builds on. Check whether each provider holds customer data, where that data is hosted, and whether it has access to your production systems. A.5.23 covers the cloud side in more depth.
Managed service providers
A managed service provider often holds privileged access to networks, endpoints or backups, which makes it a high-impact supplier even when its contract is small. Record every MSP function separately, such as monitoring, patching, backup or help desk, because each function brings different access and different risk. Confirm which of your systems the provider can administer and whether it uses its own staff, subcontractors or offshore teams.
Contractors with system access
Individual contractors and staffing firms can have the same access as employees without going through the same onboarding. List every contractor account, the systems it reaches, and the agency or company that employs the person. Ask whether the contractor's identity is governed by your identity management process, since accounts held outside it are hard to review or remove when the engagement ends.
Hardware and software vendors
Vendors that supply laptops, network equipment, firmware, operating systems or licensed software may not process your data, yet they can still introduce vulnerabilities or unauthorized code. Decide which products are in scope based on whether they run in-scope systems or connect to them. Include vendors whose update channels, remote support tools or embedded components could alter the environment, and note the products that need vendor security advisories monitored.
Data processors and outsourced development
Organizations that process personal data for you, or write code or configure systems under contract, handle information at the core of the ISMS. Treat each data processor and development firm as a supplier whose work must meet your requirements, and record which datasets, repositories or environments they can reach. Confirm whether subcontractors are involved, since their access usually extends the original supplier's footprint.
Scope statement as the filter
The ISMS scope statement sets the boundary for the supplier list, so a supplier outside that boundary generally falls outside A.5.19. Start from the in-scope information assets and processes, then trace each one to the suppliers that provide, host or support it. Record any supplier you exclude and the reason, because an assessor will test whether the exclusion is justified against the scope document.
How an assessor tests supplier risk processes
This table walks through what an assessor checks for A.5.19, from the process document through sampled supplier records to whether the process was actually followed. Read each row as a test step with the evidence it needs and the findings auditors most often raise.
| Test step | What the assessor does | Evidence requested and common finding |
|---|---|---|
| Review the process document | Checks that a documented process defines supplier categories, due diligence depth, approval and review triggers, and who owns each step | Supplier management procedure and risk criteria. Finding: the procedure exists but names no owner or does not match how teams work |
| Inspect the supplier inventory | Compares the list of suppliers with systems, contracts and payment records to see whether the population is complete | Current supplier register with service, data access and criticality. Finding: no supplier inventory, or shadow SaaS tools missing from it |
| Check categorization | Samples suppliers and asks why each was placed in its category, then tests whether that category drove the level of due diligence | Categorization record with rationale and date. Finding: every supplier is treated the same regardless of data access or criticality |
| Sample due diligence records | Selects suppliers across categories and reviews security questionnaires, certifications, reports and the reviewer's conclusion | Completed assessments, evidence reviewed and sign-off. Finding: questionnaires returned but never assessed or followed up |
| Test periodic reassessment | Checks whether higher-risk suppliers were reviewed again after onboarding, at planned intervals and after material changes | Dated reassessments and triggers such as scope or ownership changes. Finding: due diligence done only at onboarding and never repeated |
| Trace the link to risk assessment | Confirms that supplier risks appear in the ISMS risk register with treatment decisions, and that the risk register reflects supplier findings | Risk register entries and treatment plans referencing suppliers. Finding: no link to risk assessment, so supplier risks are unmanaged |
| Test whether the process was followed | Compares a sample of onboarding decisions and exceptions against the documented steps and approval rules | Approval records, exception logs and management sign-off. Finding: exceptions granted with no documented risk acceptance |
How to build the supplier risk process step by step
This sequence turns A.5.19 from a policy statement into a working process: each supplier is sorted into a category, checked to a depth that matches its risk, owned by a named person, and tracked in the risk register, with every step leaving a record an auditor can inspect.
Define supplier categories and criteria
Start by writing down what counts as a supplier for information security purposes and how suppliers are grouped. Criteria usually include access to information or systems, whether the supplier hosts or processes data, the sensitivity of that data, how hard the service would be to replace, and whether the supplier sits in the ICT supply chain. The output is a short, approved categorization document with a definition for each category and the criteria used to assign a supplier to it. An auditor will check that the categories exist, that they match the organization's information classification, and that the criteria would produce the same answer for two different reviewers.
Set due diligence depth for each category
For each category, decide what checks apply before a supplier is onboarded and what evidence the organization needs to see. Higher-risk categories might call for review of security reports, questionnaires, architecture details or on-site or remote assessment, while low-risk categories may need only a light questionnaire. Record the minimum checks per category in a standard, so the depth does not depend on who happens to run the review. The output is a due diligence matrix tied to the categories. Confirm with your own legal and procurement teams which evidence suppliers are able to provide, since this varies by supplier and jurisdiction.
Assign a named owner to each supplier
Every supplier relationship needs one accountable business owner inside the organization, and security needs a named reviewer for the technical assessment. The business owner is responsible for the relationship and its renewal, while the security reviewer signs off the due diligence result. Record both names against the supplier in the supplier register. The output is a supplier register where each entry has an owner, a reviewer, a category and a date of last review. Auditors commonly sample this register and ask whether the named people know their responsibilities.
Run due diligence and record the result
Complete the checks defined for the supplier's category before contract signature or before the supplier receives access to information. Collect the evidence, note any gaps, and decide whether the risk is accepted, accepted with conditions, or the supplier is rejected. Conditions should be carried forward into the contract requirements under A.5.20. The output is a signed due diligence record for each supplier, containing the evidence reviewed, the findings, the decision and its approver. Keep these records with the supplier register so the trail from category to decision is visible.
Link supplier risks to the risk register
Take the material findings from due diligence and enter them in the organization's information security risk register, using the same method as other risks. Each entry should name the supplier, the risk, the likelihood and impact rating, the treatment chosen and the risk owner. This connects supplier risk to the ISMS risk assessment and treatment process rather than leaving it in separate files. The output is a set of supplier-related entries in the risk register, each with a treatment and an owner. Check that the register is reviewed at the intervals the ISMS sets, since an auditor will look for this link.
Approve the process and document it
Bring the category model, due diligence matrix, roles and risk linkage together into a documented procedure and have it approved by the people responsible for information security governance and the affected business functions. Record the approval, the version and the review date. The output is an approved supplier security procedure, with the policy reference that sits above it. Auditors will check that the procedure exists, that it was approved by an appropriate person, and that it is the version people actually follow.
Train owners and confirm they follow the process
Brief the business owners, procurement staff and security reviewers on the procedure, their responsibilities and the records they must produce. Keep attendance or acknowledgement records and check, through a sample of supplier files, that the steps were carried out. Gaps found in the sample should lead to corrective action and, where needed, a change to the procedure. The output is training and acknowledgement records together with a short sample review showing the process works in practice. Confirm with your own assessor which sample size and frequency they expect for your environment.
What risk-based due diligence looks like in practice
Risk-based due diligence starts with a supplier category that the organization assigns before any questionnaire goes out. The category is a decision about how much harm a supplier could cause if it failed or was compromised: whether it will hold or process sensitive data, whether it runs a service the business cannot pause, and whether it has access to internal systems. A low-tier supplier, such as a provider of a non-sensitive subscription, might receive a short standard questionnaire and a check of its public security documentation. A high-tier supplier, such as a hosting or payment processing provider, should receive a longer questionnaire and a request for evidence. The organization writes down the criteria for each tier, the questions each tier receives and who approves the tier. Nothing in ISO/IEC 27001:2022 sets the tier thresholds, so the organization must define them and be able to explain them to an auditor.
Evidence requests should match the tier. For most suppliers, the organization asks for current certificates or independent reports where they exist, such as an ISO/IEC 27001 certificate or a SOC 2 report, and checks their scope, validity dates and the systems they cover, because a certificate that excludes the service being bought proves little. Confirm with each supplier which report or certificate covers the specific service, and whether the report period is recent enough for the risk. Where a certificate or report is missing or does not cover the service, the file should show what the organization asked for instead and why it accepted or rejected the answer.
Escalation is the step most often left undocumented. When a supplier handles sensitive data, supports a critical service, or answers the questionnaire with gaps, the file moves to a deeper review, which may include technical testing of the supplier's controls, a review of its sub-suppliers, or a contract negotiation before the service starts. The organization should record each escalation trigger, the reviewer, the decision and the residual risk it accepted. Those records, kept with the supplier's risk tier and reasoning, are the evidence that the process runs as designed. An outside assessor can help prepare this file, but the organization sets the criteria and makes and signs off each decision.
Which evidence satisfies A.5.19 and how to keep it current
Auditors testing A.5.19 look for a documented supplier process, a register of the suppliers it covers, and proof that each supplier was assessed before and after it was engaged. The cards below cover each artifact and the routine that keeps it accurate between audits.
Supplier security policy or procedure
This is the written process that defines how the organization classifies suppliers, performs due diligence, approves them and reviews them. It is the first document an assessor reads for A.5.19, and it should name the owner, the approval authority and the review date. Check that the procedure matches what staff actually do, because a mismatch between the written process and the practice in the sampled records is a common finding. Confirm the review cycle with your own policy owner, since the standard does not fix an interval.
Supplier register with categories
The register lists every supplier in scope, its category (for example, critical, important or low impact), the service it provides, the data or systems it touches, and a named business owner. It is the artifact assessors use to choose samples, so it must match procurement, accounts payable and cloud billing records. Review it on a fixed schedule and after each new contract, and record the date of the last review beside each entry.
Completed due diligence records
For each supplier, keep the questionnaire responses, certificates or audit reports received, and the reviewer's notes on gaps and accepted risks. Records should show who reviewed the answers, when, and what was decided. Where you rely on a supplier's independent audit report or certificate, keep a copy and note its scope and expiry date, so the evidence does not silently lapse.
Supplier risk assessment outputs
A risk assessment for each supplier or supplier category records the information security risks of the service, the likelihood and impact used, the controls required and the residual risk accepted. These outputs should feed the risk register used across the ISMS. Reassess when the service, data scope or supplier ownership changes, and keep the earlier versions so the history can be shown.
Approval and exception records
Approval records show that a named person with suitable authority accepted each supplier and each accepted exception, with the conditions attached. Exceptions need an expiry date and a compensating action, and they should be reviewed when they expire. Missing or undated approvals are among the easiest gaps for an assessor to find, so store them in one location with a link from the register.
Periodic review and change logs
Review logs record each scheduled reassessment of a supplier, the evidence checked, the outcome and the follow-up actions with owners and due dates. Change entries capture new sub-processors, service changes or security incidents at the supplier that triggered a review. Keep the owner sign-off and review date on every entry, and check at each quarterly governance meeting that no supplier has passed its review date without a documented decision.
What meeting A.5.19 costs in money and effort
This table breaks down the cost components of running A.5.19 supplier risk processes, separating one-time setup from recurring effort and showing who is paid for each item. Use it to frame a quote request: the drivers in the right-hand column decide where your spend goes, and no price figures are given because none are supplied for this topic.
| Cost component | One-time or recurring | Who is paid or who does the work | What drives it up or down |
|---|---|---|---|
| Defining supplier categories and the due diligence process | One-time, revisited on policy review | Internal security, procurement and legal staff; an outside consultant if engaged | Number of supplier types, how many owners must agree, and whether a template already exists |
| Supplier register and inventory setup | One-time build, then recurring upkeep | Internal owners; tooling vendor or implementation partner if a system is chosen | Number of suppliers, whether procurement data is already in a system, and data quality |
| Tooling or licenses for the register and questionnaires | Recurring license or subscription, unless self-hosted | Software vendor for commercial tools; your own infrastructure team for self-hosted open source | Per-user or per-supplier pricing terms, number of users, and whether hosting is in your own environment |
| Initial due diligence on each supplier | Recurring per new supplier and per renewal | Supplier security teams answer questionnaires; your assessors review responses | Supplier count, data sensitivity, and whether the supplier already holds a recognized certificate you can review |
| Ongoing monitoring and reassessment | Recurring, usually tied to risk tier | Named supplier owners and security reviewers | Number of high-risk suppliers, frequency of service changes, and incident history |
| Internal review and approval time | Recurring, at each assessment and at policy review | Managers, security governance and, where relevant, legal | Number of owners involved, escalation paths, and how well records are kept |
| Independent review of the process | Periodic, optional or required by your scope | Internal audit or an external reviewer independent of the supplier management function | Scope of the review, number of suppliers sampled, and whether evidence is ready |
| Certification audit sampling | Recurring at each audit cycle | Accredited certification body; the organization's staff provide evidence | Quality of the supplier records and how quickly samples can be produced |
Who owns supplier risk, who prepares evidence and who audits it
The organization owns every supplier risk decision. It decides which suppliers are in scope, how much risk it will accept from each one, whether a supplier is approved, and whether a relationship continues after a bad review. A.5.19 asks the organization to define and implement the processes for these decisions, and no outside party can take them over. Accountability sits with named internal owners, usually the information security lead for the process and the business owner for each supplier relationship.
- Decision rights: Name who approves a supplier, who can accept a residual risk and who can stop a service.
- Supplier categories: Set the categories and the criteria that place a supplier in each one, based on data access, criticality and service type.
- Register ownership: Keep the supplier register current, including owners, data handled and contract references.
- Remediation follow-through: Track due diligence findings to closure, or record the accepted risk and who accepted it.
- Management review: Report supplier risk trends to leadership so decisions are visible above the working team.
Check that each named owner can explain, without notes, why a high-risk supplier was approved and who signed that decision.
An implementation partner can help the organization design the supplier risk process, build the register and prepare the evidence an assessor will sample. This work is commonly outsourced because it is structured and takes time away from operational staff. The partner works inside the organization's own systems and documents, and it does not make the decisions above. Its deliverables should be written into a fixed scope before work starts, with the owner of each deliverable named.
- Process design: Draft the supplier categorization method, the due diligence questionnaire and the approval workflow for the organization to adopt.
- Register build: Populate the supplier inventory from procurement, finance and contract records, then reconcile it against actual usage.
- Due diligence reviews: Prepare review packs and analyze supplier security documentation, with findings handed to the organization for decision.
- Evidence preparation: Organize approvals, reviews and remediation records so the trail is complete and dated.
- Knowledge transfer: Train the internal owners so the process runs after the engagement ends.
Ask for a written list of what the partner will not do, including signing off supplier approvals or representing the organization to the certification body.
Only an accredited certification body can issue an ISO/IEC 27001 certificate, and only the independent auditor it assigns decides whether the supplier controls conform. ISO itself does not certify organizations. The certification body operates to ISO/IEC 17021-1:2015 plus ISO/IEC 27006-1:2024, and the auditor must be independent of the work that built the process. For that reason, an auditor cannot design the supplier process or build the register for the same client and then judge it.
- Sampling: The auditor selects suppliers from the register and checks whether each went through the documented process.
- Evidence testing: The auditor reviews approvals, questionnaires and remediation records for timing, authority and consistency.
- Nonconformities: Findings are raised and the organization responds with corrective action within the body's process.
- Certificate decision: The certification body alone decides the outcome and the certificate scope.
- Surveillance: Ongoing audits sample supplier reviews across the certificate cycle.
Confirm with any prospective certification body whether it accepts consultancy work from the same firm you plan to hire, and how it documents that separation.
Where organizations fall short on supplier risk
Most supplier risk failures are not exotic. They come from gaps in the basics: nobody knows the full list of suppliers, due diligence is done once and forgotten, and what the risk assessment finds never reaches the contract. The cards below cover the gaps auditors most often probe under A.5.19 and how to close each one.
No complete supplier inventory
A.5.19 starts with knowing which suppliers exist and what they touch. Many organizations keep procurement records for large contracts but lose track of smaller services, subcontracted operators and software bought on a corporate card. Build one register that lists each supplier, the information or systems it can reach, and the business owner. Reconcile it against accounts payable, single sign-on application lists and cloud billing exports. Ask the auditor to sample a supplier from the finance ledger and confirm it appears in the register.
Shadow SaaS tools
Teams often sign up for productivity, analytics or AI tools without involving security, so those suppliers never enter the risk process. Tools that handle customer or employee data create the same exposure as contracted vendors. Detect them through expense reports, OAuth consent logs, DNS and proxy records, and email domain checks. Each discovered tool should either go through the same due diligence as any supplier or be blocked and removed. Document both outcomes so the register stays accurate.
Due diligence not repeated
A supplier assessed at onboarding can change ownership, move data to a new region, add sub-processors or suffer a breach. A one-time questionnaire then becomes a stale record. Set a reassessment interval based on each supplier's category and risk rating, and trigger an early review on defined events such as a merger, a material incident or a change in service scope. Confirm with your own policy which intervals apply, and keep the completed assessments with dates and reviewer names.
Risk findings missing from contracts
When due diligence finds a weakness, such as no encryption at rest or no independent audit report, the finding often stays in the assessment file. A.5.19 expects risk decisions to influence how a supplier is used. Turn each accepted or required mitigation into a contract term, a compensating control on your side or a documented risk acceptance signed by the owner. The contract clauses themselves belong to A.5.20, so link each finding to the clause that addresses it.
No named owner per supplier
Suppliers without an accountable owner tend to drift. Nobody reviews their reports, approves their access or notices when their service changes. Assign one business owner and one security reviewer to every supplier in the register, and record both names with their role descriptions. The owner decides whether the relationship continues and signs off reassessments. Ask the auditor to confirm that each sampled supplier has a named owner who can explain the service and the last review.
Questions buyers ask about A.5.19
How much effort does A.5.19 take for a small team?
For a small team, the effort depends mostly on how many suppliers the organization uses and how many of them touch information, customer data or production systems. A.5.19 asks for a process and a risk-based approach, not a fixed number of assessments, so a team with a short supplier list and a few critical providers can keep the work light. Effort rises quickly when the supplier register is missing, when ownership is unclear, or when the team has to reassess many low-risk tools at once. Ask any implementation partner to size the work from your actual supplier list before agreeing a scope.
Can a small team do A.5.19 in-house?
Yes, many small teams do. The control needs a documented process, a list of suppliers grouped by risk, a due diligence method, and records showing that the method was applied. Those are tasks a security lead, operations owner and legal or procurement contact can handle without outside help. Outside help is most useful for designing the method once, reviewing the first set of assessments and preparing evidence for the auditor. Whatever the split, the organization keeps ownership of the decisions about which suppliers are acceptable.
What does the work need from the team day to day?
The work needs named owners who keep the supplier register current, someone who runs due diligence when a supplier is added or its service changes, and a decision-maker who accepts or rejects residual risk. Procurement needs to route new supplier requests through the same intake step, and engineering needs to flag new integrations that send data outside the organization. Records matter as much as activity. Each assessment should show the date, the reviewer, the risk rating, the evidence reviewed and the decision taken, because auditors sample these records to test whether the process runs in practice.
How long does A.5.19 take to put in place?
The timeline depends on how mature the existing supplier management is, how many suppliers need a first assessment, and how quickly the organization can agree the risk criteria. Organizations that already run vendor reviews for privacy or finance usually need less time to adapt them than organizations starting from nothing. Ask any provider for a timeline based on your written scope, and check which steps depend on your staff, such as gathering supplier documents and approving the method. Work tends to run longer when supplier data is spread across departments.
How does A.5.19 differ from A.5.20 to A.5.22?
A.5.19 is the umbrella. It asks for the processes that decide how supplier information security risk is identified, rated and handled before and during use. A.5.20 builds on it by writing the agreed security requirements into each supplier contract. A.5.21 extends the view to the ICT supply chain beyond direct suppliers, such as component and sub-supplier risk. A.5.22 covers what happens after the contract is signed: monitoring service performance, reviewing security practices and managing changes. An auditor will usually check A.5.19 first, then confirm that the later controls follow from its risk ratings.
What does a partner do and what does the auditor do?
An implementation partner helps design the supplier risk process, builds the register and assessment templates, sets up the evidence trail and prepares the team for review. The organization owns its controls and makes the risk decisions. An independent auditor or certification body is the only party that tests the control and issues any certificate. Under ISO/IEC 17021-1 and ISO/IEC 27006-1, the certification body must stay independent from the work that prepared the system, so a partner should never be the one judging whether A.5.19 is met. Confirm this split in writing before engaging anyone.
Which tools can help keep supplier risk records?
Supplier risk records can be kept in a spreadsheet, a ticketing system or a governance, risk and compliance platform. The choice matters less than whether the records stay current and can be exported for an auditor. Open-source options such as CISO Assistant (AGPL-3.0-only) can hold ISO 27001 assessments and map them to other frameworks, which can reduce duplicate evidence work. Confirm the features you need, such as supplier inventories and assessment workflows, against the project documentation in its GitHub repository before you commit to it.
How DeployOpen scopes supplier risk work
DeployOpen plans, implements and documents the supplier processes that A.5.19 asks for, and prepares the evidence an assessor will sample, inside the client's own infrastructure. The work covers the supplier register, the supplier categories, the due diligence questionnaire and the risk rating that decides how deeply each supplier is reviewed. The client owns the policy, the risk acceptance decisions and the supplier relationships. DeployOpen configures the systems that hold these records, such as a self-hosted GRC platform, and sets up the workflows that route a new supplier through assessment and approval.
Scope and deliverables are agreed in writing before work starts. A useful scoping conversation settles which supplier categories are in scope, which systems will hold the supplier records, who on the client side approves each stage, and which evidence the client's certification body or internal audit will expect to see. Ask for a written list of deliverables, the systems and environments the work touches, the client responsibilities that DeployOpen will not perform, and the handover format for the documented procedures. Confirm how the client will keep the register current after handover, since an out-of-date supplier list is one of the first gaps an assessor finds.
DeployOpen does not issue audit reports, attestations or certificates. Those come only from an independent auditor or a certification body accredited to perform the work. If your organization is preparing for ISO/IEC 27001 certification, confirm with the certification body in advance how it will sample supplier records and whether it accepts the format of the evidence produced. Keeping the implementation partner separate from the auditor is a point to settle early, so that the people who built the supplier process are not also the people who judge it.
How DeployOpen prepares supplier risk evidence
DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, and prepares the supplier risk processes and records that A.5.19 asks you to run. We do not issue audit reports or certificates; an independent certification body assesses the result.
How we scope
- Agree in writing which supplier categories, services and platforms the A.5.19 process covers.
- Confirm which systems hold information shared with suppliers and who owns each supplier relationship.
- Define the deliverables, timelines and responsibilities in a fixed-scope agreement before work starts.
How we build
- Draft the supplier risk process and due diligence steps, then review them with your risk and procurement owners.
- Configure self-hosted tooling to hold the supplier register, risk assessments and review dates inside your environment.
- Test the workflow against sample suppliers so the records show each step was completed and approved.
How we hand over
- Deliver the documented procedure, supplier register and assessment templates for your staff to operate.
- Map the evidence to the A.5.19 requirement so your internal auditor and certification body can trace it.
- Train the named owners on how to maintain records and run due diligence on new suppliers.
How we support
- Offer ongoing support, upgrades and continuous testing of the supporting platforms as a retainer.
- Update the supplier risk process when your supplier categories, services or regulatory requirements change.
- Confirm with your certification body which records it expects for the next audit, and adjust the evidence set.
