What A.5.34 asks for and why assessors probe it
A.5.34 asks the organization to identify the requirements for preserving privacy and protecting personally identifiable information (PII) that come from applicable laws, regulations and contracts, and then to meet them. If you are facing an audit or a customer questionnaire, the assessor will want to see that you have a current list of those obligations, an owner for each one, and evidence that the technical and organizational measures actually match them. The control is short, but it is hard to evidence because the obligations rarely sit in one place. Data protection duties in customer contracts often live with sales and legal, product requirements with engineering, and regional rules with local teams, so the requirement list may be incomplete before anyone tests it.
Assessors probe this control by asking how you found your PII obligations and how you know the list is current. They sample contracts with data processing terms, check whether security controls trace back to specific requirements, and look for evidence that new products, markets or customers trigger a review. A useful first step is to confirm, with your legal and privacy leads, which laws and contracts in your environment process PII, and to record each one with its owner and review date. This register is usually the piece that auditors ask for first. It also feeds A.5.31, which covers legal, statutory, regulatory and contractual requirements more broadly.
The 2022 edition carries forward control A.18.1.4 from the 2013 edition, so organizations moving from the older standard will find the same intent under a new number and location. Be clear with your team that A.5.34 is not a privacy program on its own. The control requires you to identify and meet obligations, while the wider privacy management system, with its notices, rights handling, impact assessments and governance, sits elsewhere. If you hold a separate privacy management system, such as one built to ISO/IEC 27701:2025, A.5.34 should point to it rather than duplicate it. Confirm with your certification body how it expects the two to be cross-referenced in your Statement of Applicability.
Which systems, data and third parties fall under A.5.34
A.5.34 is only as wide as the scope the organization draws around its ISMS and its PII activities. The cards below cover the decisions that most change the workload: which PII stores and processing activities are in scope, which laws and contracts apply, and how processors and sub-processors are handled. Each decision should be written down and traced to the evidence an assessor will sample.
Inventory every PII store and flow
Start from a list of where personally identifiable information actually sits: production databases, backups, logs, analytics tools, support tickets, exports and laptops. Each store and each transfer between them becomes a line the organization must justify as in scope or out of scope. Auditors commonly test this list against the asset inventory required by A.5.9, so gaps between the two show up quickly. Check that every store has an owner and a documented purpose.
Decide which processing activities are in scope
The scope boundary follows processing activities, not only systems. A customer support process that copies personal data into a ticketing tool is in scope even if the tool is a small add-on. Record each activity with its purpose, legal basis where relevant and the teams that run it. Narrowing scope by excluding a function is a decision the auditor will question, so the reason should be written in the scope statement and reviewed when the business changes.
Map applicable laws and jurisdictions
Privacy obligations depend on where data subjects live, where the organization operates and where data is stored or accessed. Identify each jurisdiction and its requirements under A.5.31, and record which apply to which processing activity. Organizations often find that one data set falls under several regimes, so a single set of controls may need extra steps for some records. Confirm the list with legal counsel, because the control only states the obligation, not the answer.
Capture contractual privacy commitments
Customer contracts, data processing terms and partner agreements often add privacy duties that go beyond statute, such as deletion deadlines, restrictions on secondary use or notification windows. Each commitment that touches PII should be listed with the system or process that meets it. Commitments that exist only in a sales contract and not in operating procedures are a common source of nonconformity. Ask the business to flag new contracts so the register stays current.
Set the role for each processing activity
Whether the organization acts as controller or processor for a given activity changes the obligations it must meet. When it processes data on a customer's instructions, its duties follow the customer's documented instructions and its contract. When it decides purposes itself, it carries broader responsibility. Record the role for each activity. Mixed roles inside one platform are common in SaaS, and they should be separated in the scope statement rather than assumed.
Bring processors and sub-processors into scope
Third parties that host, process or access PII on the organization's behalf fall within its privacy controls. Check whether each processor's sub-processors are authorized, whether notice of changes is required and whether transfers outside the approved regions are covered. A.5.19 to A.5.22 supply the supplier process, but A.5.34 requires that the contractual terms and monitoring reflect the privacy duties. Confirm each provider's data locations and deletion commitments in writing before you rely on them.
How an assessor tests A.5.34
An assessor starts by asking what the organization believes it must comply with. The first document to read is the register of applicable privacy and PII requirements, which should list the laws, regulations and contractual terms that apply, the owner of each one and the controls that answer it. The assessor then checks whether the register is current, whether it reflects the places where the organization operates and the data it processes, and whether someone is responsible for picking up changes in law. Auditors usually compare the register against the statement of applicability and the privacy notices to see whether the two tell the same story.
- Applicable requirements register: A list of privacy and PII obligations with a named owner, a review date and a link to the controls that implement each one.
- Scope of processing: Evidence that the register covers the categories of PII the organization actually handles, including data held for customers and employees.
- Change monitoring: A recorded process for reviewing legal and contractual changes, with dates showing when the register was last updated.
- Link to A.5.31: Confirmation that the privacy requirements are part of the wider legal, statutory and contractual inventory, not a separate list that drifts.
- Consistency checks: Matching entries between the register, the policy and the statement of applicability.
Before an assessment, confirm that someone outside the drafting team can explain each entry in the register and point to where it is implemented.
Contracts and public privacy notices are where the organization makes promises about PII. An assessor samples agreements with customers, processors and other third parties to check that the privacy obligations flowing from applicable law appear in them, and that the organization can show it passes those obligations down to its own suppliers. The sample is usually drawn from the contract register or the supplier list, and the assessor compares what each agreement says against the register of requirements. Privacy notices are read the same way, to confirm that what is promised to individuals matches what systems actually do.
- Data processing terms: Clauses that define roles, purposes, instructions, confidentiality of personnel and deletion or return of data at the end of the relationship.
- Sub-processor flow-down: Evidence that suppliers handling PII accept equivalent obligations and that the organization knows who they are.
- Breach notification commitments: Timelines and contacts agreed with customers, checked against the incident process.
- Privacy notices: Published statements sampled for accuracy against actual processing, retention and transfer practices.
- Contract exceptions: Records of agreements that deviate from standard terms and how the deviations were approved.
Before an assessment, pick a sample of contracts from different customer types and confirm that each privacy clause can be traced to a control and an owner.
The assessor then checks whether the technical environment does what the documents say. This is where stated obligations meet systems. Auditors typically ask for configuration evidence, access records and test results for the places where PII is stored, processed or transmitted, and they may walk through a system with the operator. Technical measures that support A.5.34 are usually shared with other Annex A controls, including data masking, information deletion, records protection and cryptography, so the assessor will often cross-check them against those controls as well.
- Configuration evidence: Settings for encryption, retention and access that match the documented privacy commitments.
- Deletion and retention: Proof that PII is removed or anonymized when retention periods end, with logs or reports as records.
- Masking in non-production: Evidence that test and development environments do not hold unprotected live PII, where the requirements call for it.
- Access to PII: Role-based access records showing who can view identifiable data and how that access is reviewed.
- Walkthroughs: Operators explaining how a sample system handles PII, which the assessor compares with the written procedure.
Before an assessment, run the same walkthrough on a system the team has not recently discussed, and check whether the evidence can be produced without rebuilding it from memory.
Assessors tend to raise a recurring set of findings against A.5.34. Most are not technical failures. They are gaps between what the organization says, what it has agreed and what it can show. Knowing these patterns helps the team prepare evidence before the auditor arrives. The findings below describe general patterns observed in assessments and are not statistics; each organization's experience will differ.
- Register not maintained: The list of privacy requirements has not been reviewed since the systems or markets it describes changed.
- Contracts not traced: Agreements exist but cannot be matched to a privacy requirement or a named owner.
- Notices out of date: Public statements describe processing or retention that no longer happens.
- Unclear boundary with a privacy system: The organization cannot explain which privacy controls sit under this control and which belong to a separate privacy management system.
- Evidence held only by individuals: Key checks depend on one person's knowledge and leave no record.
Before an assessment, ask the people who own each privacy obligation to walk through their evidence, and note any entry they cannot support with a document.
Implementing A.5.34 in six steps
This sequence takes the organization from an unknown PII footprint to a maintained register of privacy obligations, each tied to an owner and a control or technical measure that an assessor can sample. The output is a set of records an auditor can trace from law or contract, through the organization's obligation, to the evidence that it is met.
Inventory PII processing activities
Identify every place the organization collects, stores, uses, shares or deletes personally identifiable information, including SaaS tools, backups, logs, analytics platforms, test data and data held by suppliers. Business process owners and system owners contribute, and the asset inventory from A.5.9 is the starting point. The output is a PII processing inventory that lists each activity, its data categories, its systems and where the data is held. The step is done when system owners confirm the list matches what their systems actually hold.
Identify applicable laws and contracts
Work with legal counsel or the privacy function to list the privacy laws, regulations and contractual terms that apply to each processing activity, based on where the organization operates, where its data subjects live and which customer or partner contracts govern the data. The overlap with A.5.31 should be recorded here so the legal register is not built twice. The output is a list of applicable instruments per processing activity, reviewed and signed off by someone with legal authority to interpret them.
Record obligations in a requirements register
Break each applicable instrument into individual obligations, such as purpose limitation, notice, retention limits, breach notification timing, restrictions on transfers, data subject request handling and subprocessor approval terms. Record each obligation with its source, the processing activities it covers and the date it was last checked. The output is a requirements register that a reviewer can read without the underlying legal text open beside it.
Assign owners to each obligation
Name one accountable owner for each obligation, usually a role such as the privacy lead, a system owner or a contract manager, and record a deputy where the role is shared. Owners confirm they understand what they must do and how they will evidence it. The output is the register with an owner column completed, and a sign-off record showing each owner accepted the assignment. The step is incomplete while any obligation has no named person behind it.
Map obligations to controls and technical measures
For each obligation, identify the measure that meets it: an Annex A control such as A.8.10 on information deletion or A.8.11 on data masking, a technical safeguard such as encryption or access restriction, or a documented procedure such as a data subject request process. Note any obligation with no measure as a gap. The output is a mapping in the register that links each obligation to its control or measure and to the evidence an assessor can sample. Mappings between frameworks should be checked against the official crosswalks rather than assumed.
Set review triggers for legal and contract change
Define the events that reopen the register: new or amended privacy laws in the relevant jurisdictions, new customer contracts or changed terms, new processing activities, new subprocessors and significant incidents. Assign who monitors each source and how changes reach the register owners. Confirm the scheduled review interval with the organization's own policy and the management review cycle. The output is a documented review procedure and a change log showing when the register was last reviewed and what changed.
How A.5.34 relates to a separate privacy management system
A.5.34 sits inside your information security management system and asks you to identify the privacy and PII protection requirements that apply to you, under applicable laws, regulations and contracts, and then meet them. It is a single control in the organizational controls theme, so an auditor will test whether you have found the obligations, assigned owners and built them into the rest of the ISMS, not whether you run a full privacy program. ISO/IEC 27701:2025 is a different thing: it sets requirements for a privacy information management system for organizations that act as PII controllers or processors, and ISO describes it as an independent management system standard that can be used on its own. Your first decision is therefore whether you only need the A.5.34 obligation or whether a customer, regulator or contract expects a documented privacy management system with its own scope and certification.
To decide, start with the obligations you actually carry. List the privacy laws, regulations and customer contracts that touch the PII you process, including what your customers have written into their agreements. If the requirements are limited to protecting PII within your existing ISMS, A.5.34 together with A.5.31 (legal, statutory, regulatory and contractual requirements) and the records and deletion controls it depends on may be enough. If you act as a processor for many customers, handle sensitive categories of data, or must show privacy governance beyond security, a separate PIMS is more likely to be justified. Confirm with your legal and privacy advisers and, where relevant, with the customers asking for the evidence, because the answer depends on your roles and contracts rather than on the standard alone.
The NIST crosswalk from SP 800-53 Rev. 5 to ISO/IEC 27001:2022 (OLIR, October 2023) relates A.5.34 to several privacy-oriented controls: PL-2 System Security and Privacy Plans, PM-18 Privacy Program Plan, PT-1 Policy and Procedures, PT-3 Personally Identifiable Information Processing Purposes and PT-7 Specific Categories of Personally Identifiable Information. Use this as a starting point when your organization also works to NIST privacy controls, not as proof that either framework is satisfied. The crosswalk is a relationship between two sets of controls, and an assessor will still want to see your own privacy requirements register, owners and evidence.
Evidence that passes A.5.34 and how to keep it current
An assessor testing A.5.34 looks for proof that the organization knows which privacy and PII obligations apply, has mapped them to real processing and contracts, and keeps that picture current. The cards below cover the core records and technical proofs, each with the routine that keeps it accurate between audits.
Applicable-requirements register
A register listing each privacy law, regulation and contractual clause that applies to PII, with its owner, the systems it touches and the date it was last reviewed. Assessors start here to test whether the organization identified its obligations at all. Keep it current by assigning an owner to each row, reviewing the register on a fixed schedule and after any new customer contract, market entry or regulatory change. Confirm the review cadence with your own legal and privacy leads, and keep every prior version so auditors can see when a requirement was added.
PII processing inventory
A record of which systems, datasets and third parties hold personally identifiable information, the categories of data, the purpose of each activity and where the data is stored. Auditors sample it against live systems, so a register that omits a backup, log or analytics store is a common finding. Tie each entry to the asset inventory under A.5.9 and update it through change management so that new services cannot go live without a PII entry. Version history shows when processing changed.
Contract clause extracts
Extracts from customer, supplier and data processing agreements that set out PII handling duties, such as processing instructions, sub-processor rules, breach notification timing and deletion at contract end. Assessors check that the obligations in the register actually appear in signed agreements. Keep a clause library linked to each contract, and review it when agreements renew or when a sub-processor changes. Record which version of each clause was signed, since disputes often turn on wording that changed later.
Privacy notices and consent records
The privacy notices published to people whose data the organization handles, along with records showing which notice version applied when data was collected. Assessors look for notices that match actual processing, so a notice that describes a retired purpose is a gap. Review notices whenever the processing inventory changes, and store each published version with its effective date. Confirm with counsel which notice and consent obligations apply in each jurisdiction, since requirements differ.
Legal change review records
Dated minutes, tickets or memos showing that privacy and PII laws were reviewed, what changed, and what the organization did in response, such as updating the register, contracts or notices. Auditors want to see that the review happened on a schedule and after notable changes, not only at certification. Assign a named reviewer, log each review as a record, and keep the outcome linked to the register entries it affected. Ask legal advisers to confirm which regulatory sources the review must cover.
Technical proofs of protection
Configuration evidence showing that PII is protected in practice, such as encryption at rest for file stores, key management for application data and access restrictions on processing systems. Nextcloud's server-side encryption protects file contents at rest with keys kept on the server, but it does not encrypt file names or folder structure, so the assessor expects that gap to be documented and risk-accepted. Export configuration snapshots on a schedule, keep them in version control and record who approved each change. Confirm the specific settings with your own platform team before relying on them.
What meeting A.5.34 costs in money and effort
This table lists the cost components of meeting A.5.34, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Read it as a checklist for building a quote, because no fixed figures are published for these components. The main takeaway is that open-source tooling removes license spend, but staff time for legal analysis, engineering and evidence upkeep remains.
| Cost component | Who is paid or who spends time | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Legal review of PII requirements | Internal counsel or external privacy counsel | One-time to build the register, then recurring as laws change | Number of jurisdictions, sector rules and changes to data protection law |
| Privacy or counsel fees | External lawyers or privacy consultants billed by the hour or by scope | Usually one-time for the initial analysis, recurring for updates | Number of contracts with PII clauses, cross-border transfers and whether a privacy management system is also built |
| Engineering time for technical measures | Internal platform or security engineers, or an implementation partner under a written scope | One-time for encryption, access and deletion設定, recurring for maintenance | Number of systems holding PII, data stores, and whether encryption and key management are already in place |
| Contract and processor tracking | Procurement, legal and the owners of processor relationships | Recurring with each new processor or contract renewal | Number of processors, sub-processors and contract volume with PII terms |
| Evidence upkeep | Control owners and the team that maintains records and logs | Recurring throughout the certification cycle | Number of evidence sources, how often records change and how well evidence is automated |
| External review | Independent reviewers, internal audit or an assessor the organization engages | Recurring at planned intervals or after significant change | Scope of the review, number of sites and systems, and readiness of documented evidence |
| Auditor sampling | Certification body or independent auditor, paid under its own agreement | Recurring at each surveillance and recertification audit | Number of PII processing activities sampled, number of sites and quality of the evidence trail |
| Open-source software licenses | No license fee for the self-hosted platforms named on this page, subject to each license | Removed as a license line, but hosting and support still cost money | Choice of platform, hosting model and whether support is bought separately |
| Staff time to run self-hosted tools | Platform, security and privacy staff inside the organization | Recurring for upgrades, backups, key rotation and access reviews | Number of tools, team size and how much is automated or documented in advance |
Who does what for A.5.34: your team, a partner and the auditor
Your organization owns A.5.34 in full. It must decide which privacy and PII protection requirements apply, record them, assign accountability and approve how the control is met. Those decisions depend on your jurisdictions, customer contracts and the nature of the personal data you handle, and no partner or auditor can make them for you. Legal counsel or a privacy officer usually interprets the law, but the organization signs off on the outcome.
- Requirements register: Maintain a list of the applicable privacy laws, regulations and contractual PII clauses, with an owner and a review date for each entry. This links directly to A.5.31.
- Legal decisions: Record how each requirement is interpreted and which obligations apply to processing activities, including whether your organization acts as controller or processor.
- Risk acceptance and scope: Decide which systems and data flows fall within the PII protection commitments and who accepts any residual risk.
- Policy and sign-off: Approve the privacy-related policies and procedures, and confirm that the people who handle PII know them.
- Review cycle: Set the trigger for re-reviewing requirements, such as new customers, new jurisdictions or new processing purposes.
Before engaging any partner, confirm that someone inside the organization can name every requirement in the register and explain why it applies.
An implementation partner prepares the technical and operational measures that support A.5.34 and assembles the evidence the organization and the auditor will review. This work is usually technical: configuring encryption, access restrictions, retention and deletion settings, logging and the repository where evidence is stored. The partner does not decide which requirements apply, and it does not approve the control on the organization's behalf.
- Technical measures: Configure self-hosted systems so that PII protection measures in the organization's policies are actually applied, such as encryption at rest, key management and data masking where the register calls for it.
- Configuration evidence: Capture versioned configuration files, screenshots, exported settings and change records that show how each measure is set and when it changed.
- Evidence repository: Build a structured store that maps each requirement in the register to the evidence that supports it, with owners and review dates.
- Gap identification: Report where a measure is missing or inconsistent with the register, so the organization can decide how to respond.
- Documentation handover: Deliver runbooks and procedures the organization's staff can operate after the engagement ends.
In a fixed-scope engagement, check that the written scope names each measure, the systems involved and the handover format for every deliverable.
The independent auditor, assessor or certification body tests whether A.5.34 is designed and operating as the organization describes. It samples evidence, interviews staff, inspects configurations and reports the findings. Only an independent body can issue an audit report or certificate, and that body must not design the controls it assesses, because doing so would remove the independence the assessment depends on.
- Sampling and testing: Select records, systems and processing activities and check them against the register and the organization's stated measures.
- Interviews and walkthroughs: Confirm that the people handling PII understand their obligations and follow the documented procedures.
- Findings and reporting: Record any nonconformities and report on the control's status to the organization and, where relevant, to the certification body.
- Independence line: An auditor may explain requirements in general terms but should not write the register, select the measures or produce the evidence it will test.
- Certification cycle: Certification bodies operate on the cycle set by their accreditation rules, so confirm the audit timing with the body before the engagement.
Before hiring an auditor, confirm that its accreditation covers the scope and that the same firm has not built the controls for you.
Common gaps in A.5.34 and how to close them
Most A.5.34 findings come from privacy obligations that were never written down, traced to systems, or carried into contracts and change decisions. The cards below describe the gaps we see most often and a closing action for each. Each action produces a record an assessor can sample.
No register of applicable privacy laws
A.5.34 asks the organization to identify the privacy requirements that apply to it, so an assessor will ask for the list first. Teams often rely on memory or on a single regional rule, and miss sector rules, cross-border obligations and customer-driven terms. Close the gap by building a register that names each law or regulation, the processing it covers, the owner who tracks changes and the date it was last reviewed. Confirm the register with legal counsel for each jurisdiction where you process personal data.
Customer contracts without PII clauses
Contracts often carry data processing duties that never reach the security team, so the ISMS does not know what it has promised. Check whether each agreement with a customer or supplier that handles personal data sets out roles, permitted purposes, breach notification and deletion at exit. Close the gap by adding a standard PII schedule to contract templates and keeping a list of agreements with the controls each one depends on. Ask legal to flag any clause that conflicts with internal retention rules.
PII stores missing from the asset inventory
If a database, log pipeline, backup set or analytics tool holds personal data but is absent from the inventory, the privacy controls around it are unmanaged. Auditors commonly sample a production system and then check whether it is listed with its owner and data categories. Close the gap by tagging PII-bearing assets in the inventory and running a periodic discovery scan against cloud accounts and shared drives. Record each store's purpose and owner so the list can be reconciled against the register of obligations.
Encryption that leaves metadata exposed
Encryption at rest is often assumed to cover everything, yet some platforms protect file contents but leave file names and folder structure readable. Those names can reveal personal information, such as a customer name in a path. In Nextcloud, for example, server-side encryption protects file contents but does not encrypt file names or folder structure, so a team needs to decide what naming rules to apply. Close the gap by documenting what each encryption setting covers and adding naming conventions that avoid personal data in paths.
No trigger to revisit obligations on change
A new product, a new market or a new data source can add privacy obligations overnight, and a register that is reviewed once a year will lag behind. Look for a documented step in product launch, vendor onboarding and project approval that asks whether personal data is involved and which obligations change. Close the gap by adding a privacy question to the change and project intake forms, with a named reviewer who updates the register and the affected contracts before launch.
Privacy program kept apart from the ISMS
A.5.34 relates to a privacy management system, but many organizations run privacy in a separate function with its own policies, which leaves the ISMS unaware of privacy commitments. Assessors look for one place where privacy requirements feed risk assessment, access rules and incident response. Close the gap by naming an owner for privacy requirements inside the ISMS, cross-referencing the privacy program's policies and agreeing how breach decisions are escalated. If you plan to certify to ISO/IEC 27701:2025, confirm its scope with your certification body before starting.
Questions buyers ask about A.5.34
How much effort does A.5.34 take to meet?
The effort depends less on the control itself than on how many privacy obligations the organization has to identify. A.5.34 asks you to identify and meet the privacy and PII protection requirements that come from applicable laws, regulations and contracts, so the work is mostly discovery and documentation first, then engineering. Drivers include the number of jurisdictions where you process personal data, how many customer contracts carry data protection terms, the number of systems that hold PII, and whether a privacy program already exists. Ask any consultant to show how they will scope these drivers before quoting, and confirm which systems hold PII with your own data owners.
Can a small team run A.5.34 without outside help?
Yes, a small team can usually run A.5.34 in-house if one person owns the privacy requirements register and has access to legal advice for interpretation. The recurring work is keeping the register current as laws, customer contracts and products change, and showing an assessor that each requirement has an owner and a control behind it. Outside help tends to be useful for an initial gap review, for checking interpretation of unfamiliar regimes, or for building the first register quickly. Confirm internally who will review changes to the register each quarter, because that owner is what an auditor will ask about.
How long does preparation for A.5.34 usually take?
No reliable duration can be given without knowing the scope, so treat any single figure with caution. Preparation time is driven by the number of applicable requirements, the state of existing data maps and records, how many contracts need review, and whether the organization already runs a privacy management program. Organizations with mature privacy documentation generally need less time to produce the register than those starting from scratch. Ask for a written plan that lists each phase, its inputs and the people who must supply them, and check that the timeline matches your internal capacity for legal and data owner reviews.
Can a consultant write the privacy requirements register for us?
A consultant can draft the register, but the organization must own its content and approve it. The register records which laws, regulations and contractual terms apply, how each one is met and who is accountable. Only your legal counsel or privacy function can confirm legal applicability, and only your business owners can confirm how processing actually happens. An implementation partner can structure the register, link entries to controls and evidence, and prepare the supporting records. Independent auditors then test the register against reality, so ask for a clear statement of who approved each entry.
Is ISO/IEC 27701 required to meet A.5.34?
No. A.5.34 is an Annex A control of ISO/IEC 27001:2022 and does not require ISO/IEC 27701. ISO/IEC 27701:2025, the second edition published in October 2025, sets requirements for a privacy information management system for PII controllers and processors, and ISO describes it as an independent management system standard that can be used alone. An organization that needs a formal privacy management system, or that is asked for it by customers, may choose to implement 27701 in addition. Confirm with your customers and regulators whether they expect a separate privacy certification or only the controls.
What must the organization provide to an implementation partner?
The organization should provide access to people and records rather than only documents. Typical inputs include the current list of systems and data stores that hold personal data, existing privacy notices and data processing agreements, contracts with clauses about personal data, records of processing where they exist, and the names of the people who own each system. Access to the environments where the controls run is also needed so that configuration evidence can be collected. Agree in writing which decisions stay with your legal and privacy staff, so the partner prepares material without making legal determinations.
Do self-hosted tools remove the need for a privacy platform?
Self-hosted tools can support A.5.34 but do not remove the need for a privacy requirements process. Tools such as Nextcloud server-side encryption, OpenBao transit encryption and XWiki version history can protect data and keep records of changes, which supports the control. However, Nextcloud encryption does not encrypt file names or folder structure, so that metadata gap must be assessed and documented. A privacy platform or a GRC tool such as CISO Assistant can hold the register and link evidence, but the organization must confirm each tool's capabilities in its own environment before relying on it.
How DeployOpen prepares A.5.34 evidence
DeployOpen helps organizations prepare the systems, documents and evidence that show how they identify privacy and PII requirements and meet them. We run the work inside your own infrastructure, and the organization keeps ownership of its controls, its privacy obligations and its decisions. Independent auditors and certification bodies are the only parties that issue reports or certificates.
How we scope
- Engagements are fixed-scope, with the PII inventory, applicable laws and contracts and target systems agreed in writing before work starts.
- The written scope names which platforms, data stores and processing activities are covered by the A.5.34 evidence set.
- Scope also states which privacy obligations the organization owns, such as the register of legal and contractual PII requirements.
How we build
- We configure self-hosted open-source platforms in your cloud accounts, data centers or air-gapped networks to support PII handling rules.
- Technical measures such as encryption at rest, key management and access logging are set up and documented against the agreed requirements.
- Test evidence, such as configuration exports and access records, is collected so an assessor can trace each requirement to a system.
How we hand over
- Deliverables include configuration records, procedures and evidence packs mapped to the written A.5.34 scope.
- Documentation is written so the organization's privacy and security owners can maintain it after handover.
- Your auditor receives the evidence set, and any gaps we find are listed so your team can decide how to close them.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers for platforms that handle PII over time.
- Retainers can cover review of changes to PII requirements, new systems and updated platform versions.
- Ask any provider to confirm in writing which privacy decisions, legal reviews and auditor interactions stay with your organization.
