A.5.22 Supplier service monitoring and change management

What A.5.22 asks for in supplier monitoring and change management

A compliance lead preparing for an audit should know that A.5.22 asks the organization to regularly monitor, review and evaluate the information security practices and service delivery of its suppliers, and to manage changes made to those supplier services. The control covers two linked duties. The first is ongoing oversight after a supplier is onboarded. The second is controlled handling of changes the supplier makes, or the organization makes to how it uses that supplier. It merges two controls from the 2013 edition, A.15.2.1 (monitoring and review of supplier services) and A.15.2.2 (managing changes to supplier services), into one control in the 2022 Annex A. ISO/IEC 27002:2022 gives the implementation guidance for it, and that guidance is the reference an assessor will expect the organization to have considered.

The risk the control targets is quiet degradation. A supplier that passed due diligence at onboarding can later weaken its controls, change its hosting location, add sub-suppliers, alter its service terms or shift its security staffing, and none of this appears in the contract the organization signed. Monitoring is hard for three practical reasons. The supplier population is usually large and uneven, so a few critical services receive attention while the rest drift. Suppliers report in different formats, on different schedules and at different levels of detail, which makes trends difficult to compare. And changes often arrive without notice, buried in release notes, status pages or account updates that nobody owns.

Before the audit, confirm three things. First, that each supplier has a documented monitoring frequency tied to its criticality, with a named owner who receives its reports. Second, that the organization can show the reviews that actually happened, such as service reports, certificates, incident notices and review meeting records. Third, that a defined route exists for supplier-initiated changes to flow into a change record and trigger reassessment where the change affects risk. The reassessment criteria and the link to the change process are the parts auditors most often find undocumented.

Which suppliers and services fall under A.5.22

A.5.22 only works on the suppliers the organization has decided matter. Scoping starts with a tiering decision based on criticality and data access, then carries that tiering into the supplier register from A.5.19 and the agreements from A.5.20. The cards below cover the provider types auditors most often ask about and the checks that keep the list defensible.

Criticality and data access tiers

Tier each supplier by two questions: how badly would a failure of this service hurt operations, and what information or access does the supplier hold. Suppliers that host production systems, process customer records or hold privileged access usually sit in the top tier and receive the deepest reviews. Write the tiering criteria down, apply them consistently, and record the reason for every placement, because an assessor will sample the tiers against the register and ask why a given supplier was placed low.

Cloud infrastructure providers

Infrastructure, platform and hosting providers usually form the highest-impact group because they run the systems that carry the organization's information. Monitoring here means reviewing the provider's published assurance reports, tracking regional or service changes, and confirming which controls sit with the provider and which remain with the organization. Confirm the specific reports and review cadence with your own contract and account team rather than assuming coverage.

SaaS applications holding business data

Software-as-a-service tools that store customer, employee or financial data belong in scope even when they are cheap or were adopted by a single team. Shadow IT is the usual gap: a tool signed up with a corporate card may never reach the supplier register. Include a discovery step in the scoping exercise, for example by reviewing expense records, single sign-on logs and identity provider application lists, and bring every newly found service into the same tiering process.

Managed service providers

Managed service providers operate monitoring, backup, help desk or network functions on the organization's behalf, often with administrative access to its systems. Their privileged access makes them a high-priority review target even when the service looks routine. Scope the provider's access rights, its own subcontractors and the logs it generates, and confirm how incidents at the provider reach the organization within the timeframe set in the agreement.

Outsourced development and contractors

Outsourced development firms and contract engineers can introduce code, hold source repositories and reach production environments. Scope them by the access they hold and the artifacts they deliver, not by contract type. Monitoring covers how their work is reviewed before release, how their accounts are removed at the end of the engagement, and whether their own practices change during the contract, including any move of work to subcontractors.

Linking scope to the register and agreements

The supplier register from A.5.19 is the starting list, and every supplier on it should carry a tier that determines its review frequency and the depth of its contract terms under A.5.20. Check that each high-tier supplier has a current agreement with security clauses, audit rights and notification duties, and that the register shows the owner responsible for each review. Gaps between the register and the agreements are a common finding because each is maintained by a different team.

How an assessor tests supplier monitoring and change control

This table sets out how an assessor samples supplier reviews and change records for A.5.22, what evidence they request for each step, and where organizations usually fail. Read it as a checklist of what to prepare before the audit, and note that the organization owns the reviews while the auditor only tests them.

Test step	What the assessor does	Evidence that satisfies it	Common finding
Supplier population and tiering	Obtains the supplier register and checks which suppliers are classed as critical, important or low risk, then compares it with the asset inventory and contract list	Supplier register with service, data access and risk tier, linked to the agreements and the risk assessment that set the tier	Register omits suppliers that hold or process information, so monitoring never reaches them
Sampling across tiers	Selects suppliers from each tier, weighting toward those with the most sensitive data or service dependency	Monitoring file for each sampled supplier, covering the most recent review period	Only the largest suppliers are monitored, and low-tier suppliers with access to sensitive data have no record at all
Periodic service reviews	Checks that reviews happen at the interval the organization set and that each review has a date, a reviewer and a result	Dated review records, meeting notes or scorecards, and the planned review calendar	Reviews are scheduled in the procedure but never performed, or the last review is well past the set interval
Security content of reviews	Confirms that reviews assess information security, not only delivery, cost or uptime	Review templates that cover incidents, vulnerabilities, access, certifications and audit reports received from the supplier	Reviews cover service levels only and never mention security, incidents or audit reports
Supplier security reports and assurance	Checks that reports such as independent audit reports, certificates or questionnaire responses were received, read and assessed	Copies of reports or certificates with the date received, the reviewer's findings and any follow-up requests	Reports are filed unread, expired certificates are not noticed, or carve-out and exceptions are not followed up
Changes to supplier services	Looks for changes the supplier notified or that the organization identified, such as new sub-processors, hosting locations or features	Change log or ticket for each change, with the security assessment and the decision made	No record that supplier changes were assessed, so a new sub-processor or data location goes unnoticed
Acting on findings	Traces a finding from the review to a decision, a corrective action or an accepted risk, and then to closure	Action items with owners, due dates and closure evidence, plus risk acceptances signed by the right authority	Findings are recorded but no action follows, and accepted risks are never revisited
Reassessment when circumstances change	Checks that a supplier was reassessed after a significant incident, contract renewal, change in ownership or change in scope	Triggered reassessment records linked to the event that caused them	The organization reassesses only at contract renewal and misses incidents or acquisitions in between

Implementing supplier monitoring and change management in sequence

This sequence turns A.5.22 from a policy statement into a repeatable cycle: each supplier is reviewed at a frequency matched to its importance, each review leaves a record, and each supplier change is assessed before it reaches the organization's data or processes. The output is a set of dated review records and change decisions that an assessor can sample.

Classify suppliers and set review frequency by tier
The information security or supplier risk owner sorts suppliers into tiers based on the data they handle, the criticality of the service to the business and the depth of integration. Each tier gets a review frequency and a depth of review, written into a supplier review schedule. The schedule names an owner for each supplier and is approved by management. It is done when every supplier in the register has a tier, an owner and a next review date. Ask your own risk owner to confirm the tier criteria, since the standard leaves the thresholds to the organization.
Build a review checklist for each tier
The owner builds a review checklist that covers the supplier's security posture, such as its governance, access controls, incident handling and vulnerability management, along with service delivery measures such as availability, support responsiveness and any breaches of agreed service levels. Higher tiers get longer checklists. The checklist is approved and version controlled so that reviews across suppliers can be compared. It is complete when a reviewer could run it without asking the author what a question means.
Collect supplier reports and certificates
The owner requests current evidence from each supplier before the review, such as independent assurance reports, certifications, penetration test summaries, service performance reports and details of any incidents the supplier has notified. The request should match what the supplier agreement entitles the organization to receive, which is why the contract controls under A.5.20 matter here. The output is a dated evidence file per supplier. Confirm the validity period and scope of each certificate, because an expired or narrower scope does not cover the service you buy.
Record the outcome of each review
The reviewer completes the checklist against the collected evidence and records findings, the risk rating, agreed corrective actions with owners and due dates, and a decision to continue, continue with conditions or exit. The completed review record is signed off by the supplier owner and stored with the evidence. Auditors commonly sample these records against the schedule to check that reviews happened as planned and that findings were followed up.
Set a change notification route
The organization agrees with each supplier how it will be told about changes that could affect information security or service delivery, such as changes to hosting locations, sub-suppliers, service features, security controls or contact points. The route names who receives notices on each side and the channel used. It is recorded in the supplier agreement or an operating procedure. It is complete when the notification contacts are confirmed in writing and tested once, for example by asking the supplier to send a sample notice.
Assess each supplier change
When a notice arrives, or when the organization spots a change, the owner logs it and assesses its effect on confidentiality, integrity, availability and compliance obligations. The assessment decides whether the change is accepted, needs additional controls, or needs a formal review. A change assessment record captures the change, the analysis, the decision and who approved it. This record links to the change management controls described under A.8.32 where the organization manages its own changes in parallel.
Reassess suppliers when triggers occur
The owner runs a reassessment outside the normal cycle when defined triggers occur, such as a security incident at the supplier, a material service change, a failed review finding, a change in the supplier's ownership, or a change in the organization's own risk profile. The reassessment uses the same checklist and produces an updated review record and, where needed, a revised tier or review date. It is complete when the supplier register and schedule reflect the new position. Ask the supplier for its own trigger list during the first review so that both sides agree what counts as material.

What triggers a supplier reassessment

A.5.22 expects supplier reviews to happen on a regular schedule, but some events cannot wait for the next cycle. The organization must define these trigger events itself, write them into its supplier management procedure, and keep records showing that each trigger was checked when it occurred. Auditors will not accept a list of triggers that nobody applied. The usual candidates are a change of supplier ownership, a material change to hosting location or sub-suppliers, a reported security incident at the supplier, a change to the scope of the service being bought, and a lapsed or withdrawn certification or attestation the supplier previously provided.

Each trigger needs a named owner, a defined response and a record. For a change of ownership or sub-suppliers, the owner is usually the contract or vendor manager, who should compare the new details against the supplier's risk rating from A.5.19 and check whether the agreement terms from A.5.20 still hold, such as notification rights and audit rights. For an incident, the security team should review the supplier's incident report, confirm the notification met the contract terms, and decide whether the risk rating changes. For a changed service scope, such as a new product tier that processes more sensitive data, the reassessment should cover the new data flows. Where a certificate or report lapses, the organization should request its replacement and document any interim risk acceptance.

Ask suppliers to notify you of these events in writing, and confirm the notice period in each contract, since some changes may be announced only after they take effect. A ticket in a service desk tool, such as GLPI's Assistance module for changes or Zammad for supplier correspondence, can capture the trigger, the decision and the reviewer's sign-off in one place. As an illustrative check, sample a few supplier changes from the past year and confirm that each one produced a dated review record. Confirm with your own auditor which trigger list and evidence format they expect for your scope.

Evidence that satisfies A.5.22 and how to keep it current

A.5.22 is judged on a trail, not on a single review. The artifacts below connect each supplier to a dated record of what was checked, what changed and what was decided, and each needs a named owner and a review date so the trail stays current between audits. Confirm the exact sampling an auditor will apply with your certification body before you design the register.

Supplier register as the anchor

The supplier register lists every supplier in scope of A.5.22, with its service, the information it handles, its criticality, the contract owner and the date of its last full review. It is the first document an auditor asks for and the one that shows whether reviews cover the whole supplier base or only the suppliers someone remembers. Check that each entry links to the agreement under A.5.20 and to the most recent review record, and that the register is reconciled against accounts payable and procurement at least once a year, since new suppliers often appear there before they appear anywhere else. Assign one owner for the register itself.

Service review meeting minutes

Minutes from service review meetings with key suppliers show that delivery and security performance were discussed, not just assumed. Good minutes record the attendees, the metrics reviewed (incidents, availability, open vulnerabilities, support response), the decisions taken and the actions with named owners and due dates. Set a review cadence by criticality, and keep the agenda template under version control so an auditor can see the same questions were asked across the cycle. Minutes that repeat the same open action for several meetings are a finding in waiting.

Supplier security reports and attestations

Security reports and attestations, such as independent assurance reports or certificates the supplier holds, show the supplier's own control environment. Record the report type, the period it covers, the scope and any listed exceptions, and check whether the scope matches the service you use. Note the report's expiry date in the register so that a lapsed report triggers a request for an updated one. An attestation that covers a different product line or a different site than the one you use does not satisfy the review, and your file should say so.

Supplier audit reports and findings

Where a supplier's assurance is insufficient, or the contract gives you a right to audit, the audit report and its findings become evidence. Keep the report, the findings log, the supplier's remediation plan and the closure evidence together, with each finding given a severity, an owner on the supplier side and a target date. Track overdue findings in the same tool as your other risk items so that a finding does not close only on paper. If your organization relies on a supplier's own third-party audit, record that dependency and confirm the report is current.

Change notices and their assessments

Suppliers change services without always asking first. Change notices from suppliers, such as platform updates, changes to subprocessors, hosting locations or security settings, should be logged and assessed against the risk accepted when the service was approved. Each assessment records what changed, whether it affects confidentiality, integrity or availability, the decision (accept, require conditions or escalate) and the approver. Route notices to a shared mailbox or ticket queue with an owner, since an unread notice is not a monitored change.

Reassessment triggers and records

Reassessment is required when the supplier's risk changes, not only on the calendar. Typical triggers include a security incident at the supplier, a material change in service scope, a new data category, a change of ownership, or a lapsed attestation. Record each trigger, the reassessment performed, its outcome and the date the next scheduled review falls due. Define the trigger list in writing so that the reviewer applies the same rules to every supplier and the auditor can test the list against sample events.

Review ownership and calendar

Every artifact above needs an owner and a date, and the calendar is what shows the process runs between audits. Assign a control owner for A.5.22, business owners for each supplier relationship and a reviewer for security. Set review dates by supplier criticality and keep them in the ticketing system, where overdue items can be reported. Confirm with your certification body how much evidence it expects for a full cycle, because that expectation drives how far back the records must go.

What monitoring and change control costs to run

This table breaks down the cost of running supplier monitoring, service review and change management under A.5.22, showing who is paid, which costs are one-time and which recur. Read it as a checklist for building a quote, since no price or duration is stated here and the real figures depend on your supplier population and contracts. The main takeaway is that recurring review effort, not software, usually drives the cost.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it up or down
Supplier tiering and criteria setup	Internal risk or procurement staff, possibly an implementation partner	One-time, revisited when criteria change	Number of tiers and how many suppliers need individual review
Staff time for service reviews	Internal supplier owners and security staff	Recurring, per review cycle	Supplier count, review frequency set by tier, and the depth of each review
Supplier report collection	Internal staff collecting certificates, reports and SLA data	Recurring, per supplier per reporting period	Number of suppliers that issue usable reports versus those needing chasing
Ticketing and change register tooling	Software licences or self-hosted open-source platform hosting and administration	One-time setup plus recurring hosting and upkeep	Open-source options remove licence spend, but hosting, backups and admin time remain
External review of critical suppliers	Independent assessors or consultants paid per engagement	Recurring for critical suppliers, scoped per review	Number of critical suppliers, depth of testing, and whether reviews reuse supplier audit reports
Change notification handling	Internal staff reviewing supplier change notices and assessing impact	Recurring, triggered by supplier changes	Contract terms requiring notice, and the number of changes suppliers announce
Auditor sampling and evidence preparation	Internal staff preparing samples; independent auditor performs the audit	Recurring, at each surveillance or recertification audit	Number of suppliers sampled, quality of records, and how easily evidence can be retrieved
Reassessment after significant change	Internal staff and, where needed, external reviewers	Triggered, not scheduled	Frequency of supplier restructuring, acquisitions, new services and incidents

Who owns supplier monitoring, who can help, and where the auditor stops

The organization owns A.5.22 in full. Someone inside the company must decide which suppliers matter, how often their service delivery and security practices are reviewed, what a review finds, and whether a supplier change is acceptable. Those decisions are management decisions, and an auditor will ask who made them, when, and on what evidence. A partner can make the process easier to run, but it cannot accept a supplier's risk on your behalf.

Supplier criticality decisions: Named owners classify suppliers by their importance to services and data, and approve the review frequency for each class.
Review outcomes: Owners record whether a review passed, needs remediation, or triggers reassessment, and they sign off on any exception.
Change acceptance: Someone accountable approves material changes a supplier announces, such as new subprocessors, hosting locations or service terms.
Follow-through: Open findings get owners, due dates and closure evidence, not just a line in a meeting note.
Contract linkage: Review findings feed back into contract terms under the related controls on supplier agreements.

Before engaging anyone, confirm that a named person holds each of these decisions and can show the records from the last review cycle.

Where supplier monitoring usually falls short

Most A.5.22 failures are not missing policies. They are supplier reviews that never reach the people who act on them, reports that are collected but not read, and changes that nobody is assigned to assess. The cards below cover the gaps auditors find most often and the specific fix for each.

No supplier inventory tied to reviews

A supplier list kept by procurement often omits services bought on a corporate card, free tiers and self-hosted open-source components with vendor support. Without a register that links each supplier to its service, data classification and review date, the organization cannot show that monitoring covers everything it depends on. Close it by giving every supplier a record with a named owner, a criticality rating and a next review date, and reconciling the register against accounts payable and the asset inventory each year.

Reviews limited to contract signing

Many organizations assess a supplier's security questionnaire once, during onboarding, and never revisit it. A.5.22 expects monitoring of supplier practices and service delivery over the life of the relationship, so a review that stops at signature leaves changes in ownership, hosting location or security posture unseen. Close it by setting review frequency by criticality and recording what each review checked, what it found and who accepted the residual risk.

Supplier reports collected but never assessed

Teams often file SOC 2 reports, penetration test summaries and certificates in a shared folder without reading the scope, exceptions or complementary user entity controls. An auditor will ask what the organization concluded from each report and what it asked the supplier to fix. Close it by checking each report's period, scope and exceptions against the services you use, logging findings, and tracking the supplier's remediation dates to closure.

Change notices sent to an unowned inbox

Suppliers announce changes to sub-processors, regions, APIs and terms through notices that land in a general mailbox. Changes that alter security or data handling can pass unassessed for months. Close it by routing supplier change notices into a ticketing queue with a named owner, a triage category for security-relevant changes and a documented decision on whether each change needs reassessment.

Reassessment not triggered after incidents

A supplier breach, outage or missed contractual obligation often gets handled by the operations team and then forgotten by security and compliance. A.5.22 is weakened when incidents involving a supplier do not feed back into its risk rating. Close it by making any supplier-related incident in the incident record a mandatory trigger for an out-of-cycle review, with the outcome recorded against the supplier's file.

How long and how much effort does supplier monitoring take

How much effort does A.5.22 supplier monitoring take each year?

The effort depends mostly on how many suppliers are in scope, how critical their services are and how much monitoring evidence already exists. No researched figure for person-days is available, so the reliable way to size it is to ask for a written breakdown from any provider. The recurring work is predictable: collecting each supplier's assurance reports, reviewing service performance against agreed levels, checking that contact details and reporting routes still work, and recording decisions. A small supplier list with standard cloud and software providers takes far less time than a long list of data processors with custom integrations. Ask for the effort per supplier tier, the expected review frequency for each tier and who performs each step, so you can compare the quote against your own inventory.

What one-time and recurring costs come with supplier monitoring?

The one-time costs are the initial inventory of suppliers, the first risk-based tiering, the design of review templates and the setup of a register or ticketing workflow. The recurring costs are staff time for periodic reviews, collecting and reading supplier reports, handling changes and reassessing suppliers when their services or risks change. Costs rise when suppliers are numerous, when their assurance evidence is inconsistent, or when a change in a supplier's service triggers a full reassessment. Costs fall when contracts already require timely reports and notification of changes, which ties this control to A.5.20. Any quote should separate setup from run costs, state who performs each task and say what evidence will be produced at the end of each cycle.

Can an in-house team run supplier monitoring without outside help?

Yes, many organizations run A.5.22 in-house, provided the team has a named owner, a current supplier register and time set aside for reviews. The work is administrative and analytical rather than technical, so it usually fits within procurement, vendor risk, IT service management or a security team. The harder part is consistency: reviews slip when no one owns the calendar, when service changes are not reported to the security team, or when reviewers lack the authority to ask a supplier for evidence. A useful self-check is whether the team can name every critical supplier, show the date of its last review and show a record of one change that led to reassessment. If any of those answers is missing, the gap is in process rather than in skill.

What does the organization's own staff need to provide for A.5.22?

The organization owns the control. Its staff must decide which suppliers are in scope, assign a named owner for each supplier relationship, set the review frequency based on risk and keep the supplier register accurate. Business owners must confirm when a service changes, such as new features, new data locations or a change of subcontractor, because a supplier may not always report such changes promptly. Security staff must define what evidence is acceptable, such as current independent assurance reports or completed questionnaires, and decide when a reassessment is required. Legal and procurement staff must make sure contracts give the organization the right to receive these reports and be told about changes. A partner can prepare templates and run the review process, but these decisions and sign-offs must remain inside the organization.

Is outside help worth it for monitoring critical suppliers?

For critical suppliers, outside help is most useful at the design stage and for specialized technical checks, while the ongoing reviews usually stay with the organization. A partner can define the tiering method, build the review pack, set up the workflow in a ticketing or GRC tool and test whether evidence is complete before an auditor sees it. Specialist testing of a supplier's exposed services can also be arranged separately if the contract allows it. Be clear about limits: no implementation partner can issue a certificate or audit report, and an independent auditor will check the organization's process, not the partner's work. Ask any provider to confirm which tasks it will perform, which the organization must perform and how handover will work after the engagement ends.

How does A.5.22 relate to A.5.19 and A.5.20?

A.5.19 covers the overall approach to information security risk in supplier relationships, including how suppliers are categorized and assessed before and during use. A.5.20 covers the agreements, meaning the security clauses, audit rights, incident notification and end-of-contract obligations that must be written into each supplier contract. A.5.22 then puts those two into operation by monitoring, reviewing and managing change in what the supplier actually delivers. In practice, the contract from A.5.20 defines what reports and notifications are available, the risk approach from A.5.19 decides how often and how deeply to review, and A.5.22 produces the review records and change decisions. Auditors often trace a single supplier through all three, so the register, contract clauses and review records should use the same supplier identifier and risk tier.

Which tools help record supplier reviews and changes?

Tools do not change what the control requires, but they make the evidence easier to produce and sample. The GLPI Assistance module, which follows ITIL practices, can record tickets, problems and changes, and its planning and recurring ticket features can schedule periodic reviews. Zammad, a web-based helpdesk, can gather supplier communication from email and other channels into one ticket record, which helps show when a notification was received and acted on. CISO Assistant, which is published under AGPL-3.0-only, supports audits and compliance assessments against ISO 27001 and other frameworks, and can help link supplier records to the controls they support. Confirm each tool's current features and licensing in its documentation before relying on it, and check that the chosen tool can be self-hosted in your own environment.

What evidence should a reviewer expect to see for A.5.22?

An auditor will usually look for a current supplier register with risk tiers, review dates and named owners, then sample several suppliers to see the review trail. Good evidence includes the latest assurance report or completed questionnaire, notes of service performance against agreed levels, records of incidents or complaints and the decision taken after review. For change management, the auditor will look for records showing that a change in a supplier's service, such as a new subcontractor or a moved data location, was noticed, assessed and either accepted or escalated. Where a supplier did not provide evidence, the record should show the follow-up and the decision that followed. Ask your auditor which samples they will take and prepare those records in advance.

How DeployOpen scopes supplier monitoring for a fixed fee

DeployOpen engagements for A.5.22 are fixed-scope, which means the supplier services in scope, the deliverables and the timeline are written down and agreed before any work starts. For supplier monitoring, the scope conversation should start with an inventory of the suppliers whose services touch information, along with the review frequency each one needs, the systems that hold the review records and the people who own each review. The written scope then becomes the basis of the quote. Ask for it to list each deliverable by name, such as a review workflow, templates, configured tooling and an evidence index, so you can compare proposals on the same terms.

Within that scope, DeployOpen can design the supplier review workflow and its templates, then deploy self-hosted tooling inside your own cloud accounts, data centers or air-gapped network. Candidate components include CISO Assistant (AGPL-3.0-only) for tracking control status and assessments against ISO 27001, and GLPI (GPL-3.0-or-later) or Zammad (AGPL-3.0-only) for recording supplier service requests, change notices and issues as tickets. Which tools fit depends on your existing estate and on whether each capability you need is confirmed for the version you run, so treat the tool list as a starting point for the scoping discussion, not a commitment. Costs in this part of the engagement are one-time for design and deployment and recurring for upgrades, hosting and any retainer you choose.

DeployOpen prepares the systems, workflow records and evidence that an assessor will sample for A.5.22, such as review reports, service-level records, change notices and reassessment decisions. It does not issue audit reports, attestations or certificates. Only your organization owns the control and makes the supplier risk decisions, and only an accredited certification body can certify the ISMS. Before signing, confirm in writing who signs each review, what triggers an out-of-cycle reassessment and which evidence is handed over at the end, so that the engagement leaves you able to run the process without the implementer.

How DeployOpen prepares A.5.22 evidence

DeployOpen plans and builds the supplier monitoring, review and change records that A.5.22 asks the organization to keep, inside the organization's own infrastructure. The organization owns its supplier decisions and controls, and an independent auditor or certification body decides whether the evidence meets the standard.

How we scope

Agree in writing which supplier services, review cycles and change types the engagement covers before work starts.
Confirm which self-hosted platforms will hold supplier tickets, reviews and change records, and where they run.
Name the owners on the client side for supplier reviews, change approval and evidence sign-off.

How we build

Configure ticketing and change workflows so supplier service reviews and supplier-driven changes leave a traceable record.
Set up the Statement of Applicability link, supplier register and review schedule in the client's chosen GRC tooling.
Test that each review, report and change record can be retrieved and sampled the way an assessor would sample it.

How we hand over

Deliver written procedures describing how supplier reports are requested, reviewed and escalated when a change occurs.
Provide an evidence index that maps each A.5.22 record to its location, owner and review date.
Walk the client's staff through running the process so the records continue after the engagement ends.

How we support

Offer ongoing support as a retainer for updating workflows, tooling and evidence as suppliers and services change.
Re-check supplier change records after platform upgrades or changes to the client's infrastructure.
Coordinate with the client's chosen independent auditor on evidence requests, without issuing any audit opinion or certificate.