Article 28 Processor: requirements and evidence

What GDPR Article 28 requires before a processor touches personal data

Under Article 28, a controller must do two things before a processor handles personal data: choose a processor that provides sufficient guarantees of appropriate technical and organisational measures, and bind that processor to a written contract with the terms the regulation requires. Both duties sit with the controller even when a hosting provider, SaaS vendor or support contractor does the actual processing. If a compliance lead cannot show that each of these relationships passed both tests, the organization has a gap that a regulator or customer can find quickly. The exposure is not limited to paperwork. A processor that uses personal data for its own purposes can be treated as a controller for that processing, which changes who answers for it.

In practice, the first duty means assessing each vendor's security posture against the risk of the data it will hold, and recording that assessment before signature. The second duty means checking that the contract covers instructions, staff confidentiality, security measures, help with rights requests and breach obligations, deletion or return of data at the end, and audit access. Confirm with each vendor whether they operate under a general or specific sub-processor authorization, and whether they give notice of changes so you can object. The EDPB's Opinion 22/2024 makes the point that you should hold the name, address and contact person for every processor and sub-processor at all times, and that the decision to accept a sub-processor stays with you.

What makes this hard is volume and chain depth. A mid-sized organization may have dozens of processors, each with its own paperwork, and the sub-processors behind them may change without the customer seeing a notice. Vendors also return different versions of data processing terms, some of which omit required content. Ask each vendor for its current sub-processor list, its signed terms and the security evidence behind them, and record the answers in one register. Where a vendor offers the Commission standard contractual clauses, confirm which version it has accepted with your legal team before relying on them.

Which vendors and arrangements count as processors under Article 28

Whether a vendor is a processor depends on who decides why and how personal data is handled, not on what the vendor calls itself. The cards below cover the arrangements that most often arrive at a vendor review, and each one names the decision that determines whether Article 28 applies and what it asks for.

Cloud and hosting providers

An infrastructure or hosting provider that stores or runs your systems usually processes personal data on your behalf, even when it has no interest in the content. Check whether the provider can access data in plaintext, whether it operates the physical or virtual layer only, and where its support staff sit. Those answers determine how much of Article 28(3) the agreement must cover, including sub-processors such as data center operators and managed service partners.

SaaS tools that receive personal data

A SaaS product that receives customer, employee or patient records for its own service is a processor in most configurations. The question to settle is whether the vendor uses that data for its own purposes, such as training models, product analytics or benchmarking. If it does, the vendor may be a controller for that use, and the contract cannot simply assume processor status. Confirm the vendor's use terms and sub-processor list before signing.

Managed IT and support contractors

Managed service providers and support contractors often hold administrator access, which lets them read any personal data on a system. Access alone makes them processors for the work they do, and their staff must act only on documented instructions. Verify which environments they can reach, whether access is logged and time-limited, and whether remote support runs from outside the EEA, since that can trigger transfer rules.

Outsourced payroll providers

A payroll provider calculates pay and tax from employee data under your instructions, which is a processing role in most arrangements. Confirm whether the provider uses the data for its own products, such as benchmarking or advisory offerings, because that use can move it toward controller status for those activities. Also confirm that the sub-processors handling bank and tax data are listed and that the contract covers return or deletion at the end of service.

Analytics and data enrichment vendors

Analytics firms and data enrichment providers are the arrangements most likely to be controllers in disguise. If a vendor supplies its own datasets, combines your records with third-party data, or keeps data to improve its general services, it is deciding purposes and means for that processing. Under Article 28(10), a processor that does so is treated as a controller for that processing, so role checks must come before the contract is drafted.

Vendor chains and sub-processors

Each processor may engage sub-processors only with the controller's written authorization, either specific or general. Under general authorization, the processor must notify you of intended changes so you can object. Map the chain for every processing activity, record each sub-processor's name, address and contact person, and confirm that the contract requires the same obligations to flow down. The EDPB's Opinion 22/2024 states that the final decision to engage a sub-processor remains with the controller.

How an assessor tests Article 28 in a processor review

This table compares what an assessor does, what evidence they request and where findings usually arise when testing a controller's processor program against Article 28. Read it as a checklist of the controller's own file: the assessor tests that evidence and does not certify the vendor.

Test step	What the assessor checks	Evidence requested and common findings
Sample processor contracts	Selects a sample of processing agreements and confirms each is in writing, including electronic form, and tied to a specific processing activity	Signed agreements with dates and scope. Finding: contract missing for a hosting or support provider that receives personal data
Compare terms with Article 28(3)	Checks each contract for the required terms: documented instructions, staff confidentiality, Article 32 measures, sub-processor conditions, rights and breach assistance, deletion or return, and audit information	Clause-by-clause mapping kept by the controller. Finding: audit rights limited to a vendor report with no right to information or inspection
Review the due diligence file	Tests whether the controller relied on processors providing sufficient guarantees before engaging them, and whether that reliance was refreshed	Questionnaires, security documentation, certifications the vendor holds, and dated review notes. Finding: onboarding approved with no review after the service changed
Trace sub-processor authorizations	Confirms prior specific or general written authorization existed, that change notices were sent, and that the controller had a real opportunity to object	Authorization records, notice logs and objection decisions. Finding: sub-processors added without notice or with no current list
Check sub-processor identity records	Tests whether the controller holds the name, address and contact person of each processor and sub-processor and can produce them on request	Current register with contact details. Finding: list out of date or held only by the vendor
Test flow-down of obligations	Looks for the same data protection terms passed to sub-processors by written contract	Sub-processor agreements or contract summaries. Finding: no evidence that the sub-processor is bound to the same terms
Check end-of-contract handling	Confirms the controller has a process to require deletion or return and to verify it	Termination records, deletion confirmations and retained-data justifications. Finding: no request made when the contract ended
Confirm the controller's role analysis	Checks whether a processor acting beyond documented instructions has been treated as a controller for that processing	Instruction records and any review of processor purposes. Finding: vendor uses customer data for its own product development with no assessment

Steps to build Article 28 into vendor onboarding

This sequence turns Article 28 from a contract clause into a repeatable onboarding path, so each processor is identified, classified, vetted, contracted and monitored before and after it touches personal data. Each step leaves a named record that an assessor or regulator can ask to see.

Inventory processors and sub-processors
Start by listing every external party that handles personal data on the organization's behalf, including hosting providers, SaaS tools, support contractors and the processors those vendors themselves use. Record the legal name, service, data categories, processing locations and a named contact for each. Ask each vendor to disclose its sub-processors, because the EDPB's Opinion 22/2024 expects controllers to hold the identity and contact details of all processors and sub-processors. The output is a processor inventory that is reviewed by the privacy lead and the system owners, and that is complete for every system holding personal data.
Classify each relationship by role
For each inventory entry, decide whether the party is a processor, a controller, or a joint controller. Article 28(10) means a processor that decides its own purposes or means becomes a controller for that processing, so check contract terms, product features and the vendor's own use of data, not only the label in the agreement. Mark relationships where Article 26 or a separate controller duty may apply. The output is a classification column in the inventory, signed off by legal or the DPO function, with the reasoning written in one line per entry.
Run due diligence against the risk
Article 28(1) requires controllers to use only processors that provide sufficient guarantees for appropriate technical and organizational measures. Set the depth of review by the data categories, volume and risk involved, then request evidence such as security documentation, independent assurance reports where the vendor holds them, encryption and access control descriptions, breach handling procedures and sub-processor lists. Assess the answers against the organization's own security baseline. The output is a due diligence file per processor with the evidence reviewed, the findings, and a decision to proceed, proceed with conditions, or reject. Do not treat a certificate as proof of guarantees on its own, since the GDPR requires no certificate.
Negotiate or adopt a contract with every required term
Use a written data processing agreement, which may be electronic under Article 28(9), that includes each term Article 28(3) requires: documented instructions, staff confidentiality, Article 32 measures, sub-processor conditions, help with rights requests and Articles 32 to 36, deletion or return at the end, and information and audit access. Where suitable, the parties can base the agreement on the Commission standard contractual clauses in Implementing Decision (EU) 2021/915. Legal counsel should confirm the wording. The output is a signed agreement, with a checklist showing where each required term appears in the document.
Record sub-processor authorization and objection rights
Article 28(2) requires prior specific or general written authorization before a processor engages another processor. Decide which model applies to each vendor. Under general authorization, confirm the contract requires advance notice of intended changes and gives the controller a practical right to object before the change takes effect. Log the authorization type, notice period, objection route and the current sub-processor list in the register. The output is a sub-processor register entry for each processor, linked to the signed agreement and to the notification channel the privacy team monitors.
Register the processor and connect it to processing records
Add each approved processor to the central register with its role, data categories, purposes, locations, transfer mechanism where relevant, security evidence location and contract reference. Link the entry to the controller's record of processing activities under Article 30, so the record can be produced to a supervisory authority on request. Make sure access to the register is restricted and changes are logged. The output is a live register entry that shows the processor's status is approved and can be traced from a system to its contract.
Set a review cycle and triggers
Article 28 is not a one-time check. Schedule periodic reviews of each processor's evidence, sub-processor list and contract, and add event triggers such as a new sub-processor notice, a security incident at the vendor, a material change in service or a change in processing location. Assign an owner for each review and record outcomes. Where a processor's behavior moves beyond the documented instructions, Article 28(10) may make it a controller for that processing, so escalate those cases to legal. The output is a review calendar and a dated log of completed reviews and decisions, kept with the register.
Keep the evidence trail in version-controlled documentation
Store the inventory, due diligence files, signed agreements and review logs in a documentation platform that keeps history, so the organization can show what was decided, when and by whom. XWiki records changes to pages with version comparison and rollback, and BookStack lets administrators limit who can view or edit each section. Confirm current capabilities with the vendor and test them in the organization's own environment before relying on them. The output is a controlled evidence library, with access restricted to the privacy, legal and security teams that maintain it.

What counts as sufficient guarantees in a due diligence file

Article 28(1) requires a controller to use only processors that provide sufficient guarantees, but the regulation does not list the checks that prove it. The controller has to reach a reasoned judgment, based on the nature, scope, context and risk of the processing, and then be able to show how it got there. A file that contains a signed contract but no record of why the processor was judged capable will not carry much weight with a supervisory authority. Treat the due diligence file as the place where that reasoning lives, with dated evidence behind each conclusion.

The evidence that usually supports the judgment includes the processor's security documentation, such as its description of technical and organisational measures, its access control model, encryption approach, logging and backup arrangements, and its incident response process. Where the processor holds an independent assurance report, ask which report, which scope, which period and whether any exceptions were noted, because a report that does not cover the hosting service you are buying is of limited use. Request the processor's current sub-processor list with the name, address and contact person of each party, since the EDPB's Opinion 22/2024 expects that information to be available to controllers at all times. Ask for the processor's incident history for a defined period and how it was disclosed to customers.

Test the processor's operational commitments before you rely on them. Ask how it would support an access or erasure request within the timescale you need, how it would find data across its systems and backups, and how quickly it would notify you of a personal data breach so that you can meet the 72-hour window in Article 33. Ask for the contact route and the on-call arrangement, and ask for these commitments in the contract, not only in a sales document. Confirm with each vendor which assurance reports it currently accepts and what they cover, and take advice from your own counsel on how the file should be judged, since the list of acceptable evidence can change.

Evidence that passes an Article 28 review

An Article 28 review tests whether the contract, the sub-processor controls and the due diligence record agree with how the processor actually works. The six artifacts below connect those three things, and each one goes stale unless someone owns it between audits.

Signed processing agreement

The written agreement must contain every term Article 28(3) requires: documented instructions, staff confidentiality, Article 32 measures, sub-processor conditions, help with rights requests and Articles 32 to 36, deletion or return, and audit access. Check that the signed version matches the template your legal team approved, and that each term maps to a clause someone can point to. Keep the signed copy, its version history and the date of the last amendment in one place. Review it whenever the service scope or hosting location changes.

Commission standard clauses in use

Where the parties rely on the Commission's standard contractual clauses for Article 28(7), the evidence is the exact clause set adopted by Implementing Decision (EU) 2021/915, with annexes completed for the actual processing, data categories and security measures. An assessor will look for blank placeholders and annexes that describe a generic service rather than yours. Record which version was signed and whether any clause was modified, because modifications can affect whether the template still applies as written.

Sub-processor register

Assessors expect a current list of every sub-processor with its legal name, registered address, processing location and a named contact, and the EDPB's Opinion 22/2024 says the controller should have this identity available at all times. Ask your processor to commit to notifying you of changes and to keep the register on a stable URL or in the contract annex. Reconcile the register against the sub-processors actually named in the signed agreement at each review, not only when the list is first shared.

Authorization and objection records

Article 28(2) requires prior written authorization for each new sub-processor, either specific or general. Under general authorization, the record that matters is the change notice, the date it was sent, the objection window and what happened to any objection. Store each notice, each objection and the decision that followed, so you can show that you approved or rejected every change. Gaps here are among the most common findings when a processor has changed hosts or added a support vendor.

Due diligence file per processor

Article 28(1) requires you to use only processors that give sufficient guarantees, so the file should show how you reached that judgment. Include the security assessment, the certifications or audit reports the processor holds, its answers to your questionnaire, any transfer impact assessment and the risk rating you assigned. Ask for named reports with dates and scope statements rather than a logo on a website. Reassess each file on a schedule you define and whenever the processing or the processor's controls change materially.

Deletion or return certificate at exit

When the contract ends, Article 28(3) requires the processor to delete or return the personal data at your choice. The evidence is a written confirmation that names the systems, backups and sub-processors covered, the method used and the date completed, and where a backup retention window applies, the date it expires. Ask for this confirmation from each sub-processor as well. Test the exit procedure on a sample dataset before you need it, so the certificate describes what actually happened.

What Article 28 compliance costs in money and effort

This table breaks the Article 28 workload into cost components, showing who is paid for each, whether it is one-time or recurring, and what makes it grow. Use it to frame a quote request and to decide which parts stay in-house. No fees or durations are stated because none are supplied, so ask each provider to price these components against your written scope.

Cost component	Who is paid or who does the work	One-time or recurring	What drives it up or down
Legal review of processor contracts	In-house counsel or an outside privacy law firm	One-time per contract, then recurring at renewal or change	Number of processors, whether you start from standard clauses or from each vendor's own terms
Due diligence per processor	Your security and privacy team, sometimes with an outside assessor	Initial review, then recurring reassessment	Data sensitivity, hosting location, and whether the processor supplies current security evidence
Negotiation with large vendors	Your procurement and legal staff, plus vendor account teams	One-time per agreement, sometimes repeated at amendment	Vendor contract leverage, how much you must change from their standard terms, and volume of your spend
Cross-border transfer review	Counsel and privacy staff, sometimes a specialist adviser	One-time per transfer route, then recurring as routes change	Whether data leaves the EEA, remote support access from outside the EEA, and sub-processors in other countries
Register and tooling	Your team to build the register, plus any licensed or self-hosted tooling	Setup one-time, maintenance recurring	Number of processors and sub-processors, and whether the register is linked to contracts and reviews
Sub-processor change monitoring	Your privacy or vendor management team, and the processor's notice process	Recurring, continuous	Frequency of vendor changes, length of your objection window, and how many layers of sub-processing exist
Periodic review and audit of processors	Your staff, outside auditors, or the processor's own audit reports where you accept them	Recurring, usually on a set schedule and after incidents	Risk tier of each processor, contractual audit rights, and whether the processor's evidence is current
Central records and contract terms	Your team, with support from an implementation partner if engaged	Largely one-time, with recurring upkeep	Whether terms are standardized, so clauses and processor details are reused rather than rewritten

How self-hosted open-source tools hold processor evidence

Article 28 leaves the controller with a continuing duty to check processors and sub-processors, not a single signature. The three tools below can hold the parts of that file that a controller or its implementation partner maintains inside its own infrastructure. Each card names one job, what to decide before adopting it, and what to confirm in your own environment.

Framework assessments for GDPR

CISO Assistant (AGPL-3.0-only) ships GDPR among its more than 200 frameworks and can run assessments and audit records against them. For Article 28, the useful question is whether processor reviews can be recorded as assessments with dated answers, owners and linked evidence, such as a returned questionnaire or a signed processing agreement. Confirm the mapping it applies between frameworks before relying on it, because a mapping is a starting point and not a legal finding about a specific processor.

Version history for the processor register

XWiki (LGPL-2.1-or-later) keeps every change to a page under version control, recording what changed, when and by whom. Applied to the processor register and clause templates, this shows when a sub-processor was added, when a transfer mechanism changed, and who approved the edit. Test whether the comparison and rollback features work on the pages you plan to use, and decide who is allowed to roll back a register entry.

Role-based edit control

BookStack (MIT) gives each user abilities from assigned roles, and permissions can be overridden per role at the shelf, book, chapter or page level. Use this to separate who can read the processor register from who can change a sub-processor entry or an approved clause template. Verify the permission model in a test instance with the roles you intend to use, since an override set too broadly can expose the register to editors who should only comment.

Who does what in Article 28 work

The controller keeps the decisions that Article 28 places on it. It decides whether to use a given processor, judges whether that processor offers sufficient guarantees, and accepts the residual risk of each engagement. Legal and privacy staff approve the processing agreement, while security and procurement staff review the technical and organizational measures the processor describes. Under Article 28(2), the controller also decides whether to authorize each sub-processor or to object to a proposed change, and the EDPB's Opinion 22/2024 confirms that the final decision on sub-processors stays with the controller.

Processor engagement decisions: Record who approved each processor, the purpose, the data categories and the basis for the decision.
Contract approval: Sign off the written terms, including instructions, deletion or return at the end, and audit rights.
Sub-processor authorization: Decide on specific or general authorization and keep a process to object to changes.
Risk acceptance: Document any residual risk and who accepted it at the right level of seniority.
Instructions: Issue documented instructions that match what the processor actually does.

Check that every processor has a named internal owner who can explain why it was engaged and what would cause it to be removed.

Where processor contracts usually fall short

Most processor agreements look complete on paper and fail when a controller tries to use them. The gaps below cluster around three questions: who is actually processing the data, whether the controller can still say no, and whether it can verify what the processor does. Each card names one gap and the first step to close it.

Sub-processor list is stale

A sub-processor list that was accurate at signing often drifts within months as vendors change hosting regions, add tooling or acquire companies. Article 28(2) only works if the controller knows who is engaged at any moment. Ask for each sub-processor's legal name, processing location, a contact person and the services it performs, and confirm the list is dated and versioned. Under the EDPB's Opinion 22/2024, controllers should have this identity information available at all times.

Objection process does not work

Many contracts grant general authorization for new sub-processors but give no practical way to object. Article 28(2) requires the processor to inform the controller of intended changes so the controller can object, which means notice must arrive early enough to act. Check the notice period, the channel used, what happens to the service if the controller objects, and whether termination without penalty is available. Test the process once before you rely on it.

No audit or information rights

Article 28(3) requires the processor to make available the information needed to demonstrate compliance and to allow audits, including inspections by the controller or an appointed auditor. Some contracts offer only a summary report and exclude on-site or remote inspection. Confirm the contract covers audit scope, frequency, notice, cost allocation and how sub-processor audits are handled. Where the processor offers third-party reports, confirm what they cover and who issued them.

Deletion at exit is unspecified

Article 28(3) requires the processor to delete or return personal data at the end of the services, at the controller's choice. Contracts that say only that data will be deleted leave open the timeline, the format of any export, whether backups are purged, and how sub-processors are told. Specify the return format, the deletion window, the certificate or confirmation of deletion, and how long backups persist. Ask the processor to describe its exit procedure before signature.

Staff confidentiality is not evidenced

The contract must require persons authorized to process data to commit to confidentiality, but a clause alone does not show that staff, contractors and support engineers actually signed commitments. Ask how commitments are recorded, whether they survive employment, and which roles have production access to customer data. Request confirmation that access is limited to personnel with a documented need and that training covers handling of personal data.

Processing beyond documented instructions

Article 28(3) limits the processor to documented instructions from the controller, and Article 28(10) treats a processor that determines purposes or means as a controller for that processing. Gaps appear when support staff, analytics features or AI training use data for the provider's own purposes. Check that the contract lists the instructions, that the processor's product terms do not permit secondary use, and that the controller can change instructions in writing.

Questions buyers ask about Article 28 processor work

How much effort does a full processor vendor review take?

The effort depends on how many processors and sub-processors the review covers, how much of their documentation already exists, and how many data flows you need to map first. A review starts with an inventory of every processor and sub-processor handling your personal data, then checks each one for sufficient guarantees under Article 28(1), reviews the contract against the mandatory terms in Article 28(3), and confirms how sub-processor changes are authorized and communicated. Most of the work sits in the data flow mapping and contract review, not in the questionnaire itself. No fact supplied here gives a duration, so ask any partner for a written scope that lists the vendors, documents and deliverables before agreeing to a figure.

Can we use the European Commission standard contractual clauses for processors?

Yes. Article 28(6) and (7) allow controllers and processors to base their contract on Commission standard contractual clauses, and Implementing Decision (EU) 2021/915 sets out a set of clauses for controller and processor relationships. Using them does not remove the need to complete the annexes accurately, describe the actual processing, list approved sub-processors and state the security measures. Your legal team should confirm that the clauses fit each processing relationship, because an unchanged template with blank annexes will not show that Article 28 terms are met. Check the text on EUR-Lex before drafting.

How long does a processor contract review usually take?

No researched figure is available for this, so the timeline is driven by factors you control and factors you do not. The main drivers are the number of processors in scope, whether the vendor already has a data processing addendum that meets Article 28(3), how many rounds of negotiation the vendor requires, and whether sub-processor lists are published and kept current. Ask any provider to break its estimate into the review, the drafting of required terms, and the negotiation step, and to state which of those depend on the vendor's response times.

What does this work need from our legal and procurement teams?

Legal and procurement own the contracts, so they must be involved from the start. Legal reviews whether each contract contains the required terms, including documented instructions, staff confidentiality, security measures, assistance with rights requests and breach obligations, deletion or return at the end, and audit rights. Procurement needs to add a clause to its onboarding process so no new processor starts without a signed contract and a sub-processor list. Both teams should agree on who approves sub-processor changes and how objections under Article 28(2) are handled. Expect to give access to existing vendor contracts, purchase records and the internal owners of each system.

Can we run the processor review in-house?

Yes, many organizations do. An in-house review works when the team can map its data flows, read contracts against Article 28(3), maintain a current list of processors and sub-processors, and record decisions in a form an assessor can test. The EDPB's Opinion 22/2024 says controllers should have the name, address and contact person of all processors and sub-processors available at all times, and that the decision to engage a sub-processor stays with the controller. Outside help is usually useful for a first pass across many vendors, for technical checks of hosting and open-source platforms you run yourselves, or for building the evidence file. Keep ownership of the final decisions in-house in either case.

Can a partner issue a GDPR compliance certificate for our processors?

No. The GDPR requires no audit, attestation or certificate, and a partner such as DeployOpen cannot issue one. Certification under Article 42 is voluntary and is issued by accredited certification bodies or supervisory authorities, while any independent audit report comes from an independent auditor or assessor. What an implementation partner can do is prepare your processor inventory, contract evidence, technical settings and documentation for review. Responsibility for compliance stays with you as controller, and you should confirm with any certification body or assessor which evidence they will accept before the work starts.

Does a DeployOpen engagement cover processor contract drafting?

DeployOpen works on systems, controls and evidence inside your own infrastructure, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Where self-hosted open-source platforms form part of your processing chain, DeployOpen can document their configuration, access controls, logging and backup evidence to support the security terms in your contracts. Contract wording itself is a legal matter for your counsel. Ask for the written scope to state exactly which documents, technical evidence and sub-processor records are included.

How DeployOpen prepares Article 28 evidence for self-hosted platforms

DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, so the processor evidence Article 28 asks for can be prepared alongside the system itself. We prepare the systems, configurations and records; the controller owns its contracts and decisions, and independent parties give any legal or assessment conclusions.

How we scope

Agree a written scope that names the platforms, hosting locations and personal data categories covered by the processor review.
Map which vendor, hosting and sub-processor relationships the client holds, and which ones DeployOpen itself would become part of.
Confirm with the client's counsel which Article 28 contract terms already exist and which must be negotiated or added.

How we build

Configure the self-hosted platform so access, logging and data location match the processing instructions the client documents.
Set up change records and version history so each instruction and configuration change can be traced to a date and an approver.
Test the deletion and return paths for client data so end-of-contract obligations can be shown to work, not only written down.

How we hand over

Deliver a written inventory of systems, hosting sites, administrators and sub-processors for the client to review and keep current.
Provide runbooks for audit requests, information requests and data return, so the controller can answer processor questions on time.
Document each configuration decision and its evidence in a format the client can store, review and provide to its own assessors.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope engagement ends.
Update the sub-processor inventory and evidence pack when platforms are upgraded, moved or when a new sub-processor is added.
Ask the client to confirm any legal reading of Article 28 with qualified counsel, and to confirm with its auditor what evidence it will accept.