The necessary ones make the site work. The others measure which pages help and which ads bring the people who need DM11. Your choice, and you can revisit it from the footer.
ISO/IEC 27701
Until 2019 this standard was an extension, and nobody certified privacy without first building an entire security management system. The October 2025 revision ended that requirement. For a company that already treats personal data seriously and now has to prove it to a customer or a regulator, the road got significantly shorter.
DM11 prepares your company and runs the implementation. The audit and the certificate come from an accredited certification body that you contract. The standard covers privacy management and does not replace legal advice on data protection law: the two go together, and DM11 has digital law specialists on the team.
Who runs the implementation
Data protection specialists certified by EXIN (DPO, PDPP and PDPF)
ISO/IEC 27001 Lead Auditor certified by BSI
Legal advisory in privacy and data protection
17 years of governance, risk and compliance
WHAT CHANGED, AND WHY IT MATTERS
ISO/IEC 27701 sets the requirements for a privacy information management system. It organises how a company decides what it may do with personal data, who answers for each decision, and how that is evidenced over time. In the revision published on 14 October 2025 it stopped being an appendix to security and started standing on its own.
This is the change that rewrites the budget. In the 2019 version, certifying privacy meant having or building the whole security management system first. The standard is now self-contained, and a company can certify privacy without going through 27001. If you received a recent proposal saying otherwise, it was written against the old version.
The revision adopted the harmonised structure of clauses 4 to 10, the same as ISO 27001 and ISO/IEC 42001 for AI governance. In practice, a company already running one of those reuses context, leadership, planning and management review instead of maintaining three parallel systems.
Annex A separates the controls by role: one set for controllers, another for processors, and a block that applies to both. Defining your role in each processing activity is the first decision of the project and the one that most changes its size. Many companies are a controller in one flow and a processor in another.
The standard carries annexes linking the controls to the GDPR and to other privacy references, including the 2019 version for anyone migrating. That is what makes the certificate useful as an answer to a European customer, and what saves work for a company that already organised itself for a data protection law.
WHO USUALLY NEEDS IT
Data protection law already obliges you, and nobody certifies a law. ISO 27701 comes in when you have to prove to third parties that the obligation is being met with method.
A contract with an EU company usually demands guarantees about personal data processing. An internationally recognised certificate answers that better than a dossier assembled in a hurry, and it answers once for every customer rather than one at a time.
A company that processes data on someone else's behalf receives a privacy questionnaire from every customer, each in a different format. The certificate swaps that queue for a single document, and the processor control set was designed for exactly that role.
An enforcement action, a reported incident, or a sector that became a priority. A working privacy management system is the difference between demonstrating diligence with dated documents and trying to reconstruct the story after the question has arrived.
STORIES
We change our clients' names with the same confidentiality that will protect your company later. The names change; the pattern repeats. Where a client agrees, we give named references in a conversation.
Payroll and benefits services
The company processed the personal data of thousands of its customers' employees and treated all of it as if it were its own. The contracts did not say who answered for what, and a large customer opened a privacy audit the company had no way to answer.
We started by separating the roles flow by flow: where it was a controller and where it was a processor. That distinction changed the whole design of the programme and much of the contractual wording. The inventory of processing activities, the legal bases and the processor control block followed.
The customer's audit was answered with a document instead of a meeting. The company then began using the same material commercially, because its processor role was clear in the contract and stopped being an argument at every renewal.
Technology, serving Europe
The company had run a data protection compliance project two years earlier, with good results and no maintenance since. When a European customer asked for evidence of adequate processing, what existed was an out-of-date report and the memory of the people who took part.
We reused what the earlier project had left behind, which was more than the board expected, and what was missing was precisely the management system: who reviews, when, with what record. We built that and mapped the controls against the GDPR using the standard's own annexes.
The company ended up with a system that maintains itself and a mapping ready to answer European customers. The earlier project stopped being a sunk cost and became the base of the new one.
Private healthcare
The operation handled health information, which the law treats as sensitive personal data, and applied the same controls to it as to everything else. There was no intent to get it wrong: nobody had made the distinction on paper, so it did not exist in practice.
We classified the processing activities by the nature of the data and reinforced where the law demands more: a specific legal basis, tighter access control, a record of who consults what, and retention periods set by type of information.
The difference showed up in access control: dozens of people could reach patient records with no functional need, and nobody knew because there was no log. After the project, access became justified, logged and reviewed.
SELF-ASSESSMENT
Twenty questions: two to understand your case and eighteen on what the standard asks for. The full result appears on screen, with a score for each domain and an honest read on what is missing. It is self-declared, so it stands as a picture of what you know today, and not as a conformity assessment.
The reading for each area, across the three result ranges. It is the same text emailed to those who identify themselves, published here for anyone who wants to understand what the score measures before answering.
Below 50
With no written scope and no officer with a mandate, every privacy decision gets made twice: once by the area that needs it and once by legal, when the matter gets there. The first step is cheap: one page saying which operations, units and systems are inside the management system, approved in a meeting and dated. Then formalise the officer's appointment with a date and publish the contact channel, because data protection law already asks for that regardless of any certification. Until that pair exists, scope and owner, every control you implement is ownerless the next day.
50 to 79
The role exists and the mandate does not. The symptom repeats: the officer holds the duty on top of another job, solves whatever reaches them and has no space on the leadership agenda. Set aside formal time for the role and create a fixed privacy slot in the leadership meeting, even a short quarterly one, with a record of what was decided. It is the difference between someone tasked with answering and someone with the authority to change the process that generated the question.
80 or above
Scope, appointment and reporting are standing. What usually goes missing in this band is updating the scope when the company changes: a new product, an acquisition, a new country or an area that started handling data it did not handle before. A scope written once and never revisited is the quietest finding in this domain, because it looks right until someone asks for the date of the last review. Schedule that review alongside the management review, so the two happen in the same cycle.
Below 50
Without an inventory, everything that comes after is guesswork: you cannot say which legal basis applies, how long to keep the data or where it goes. Start with the processes that generate the most personal data, which are almost always human resources, sales and customer service, instead of trying to cover the whole company at once. For each activity record four things: which data, what for, who owns it and where it goes. A short and truthful inventory is worth more than a complete and out-of-date one.
50 to 79
The inventory exists and has aged, and the reason is usually the same: it was made by a project and not by an owner, so when the project ended nobody was responsible for updating it. The fix is to name an owner per area and tie the update to a trigger that already happens, such as a new system going live or a supplier being contracted, instead of relying on an annual campaign. Check as well that the role is recorded activity by activity, because an inventory that sets the role only at company level hides precisely the flow where the company is a processor.
80 or above
The inventory is alive and has an owner. Attention now goes to the edges: a department spreadsheet, a tool bought on a credit card and an old integration still exporting data tend to sit outside the official map. A sweep through paid suppliers and active integrations finds, in almost every company, at least one processing activity nobody had declared. As long as the inventory is fed only by whoever remembers to declare, it measures goodwill and not reality.
Below 50
With no recorded legal basis, the company cannot answer the simplest question a data subject or an auditor asks: why do you have this data. Recording is not picking the most comfortable basis, it is writing the decision down and saying who made it. Start with the highest volume processing activities, follow with the most sensitive ones and take each to legal before settling it. Until that exists, the purpose declared in the notices and the real purpose of the operation remain two different things.
50 to 79
The pattern in this band is resting almost everything on a single basis, usually consent or legitimate interest, because that is the one the previous project chose. Consent creates duties of collection, recording and withdrawal that almost nobody operates in practice; legitimate interest without a written test does not hold when it is challenged. Review human resources and marketing first, the activities that most often change basis when someone looks closely. And check whether the notices outside the website, in contracts, in the app and in recruitment, kept up with the last revision.
80 or above
The bases are recorded and reviewed. What sustains the score from here is the link between purpose and real use: a purpose declared too broadly looks protective and does the opposite, because it opens room for uses nobody approved. Take two or three processing activities, ask the area what it does with the data and compare with what is written. When a difference shows up, the problem is rarely the legal basis, it is the purpose that has aged.
Below 50
With no channel and no defined deadline, the first hard request is solved by improvisation, and improvisation cannot be demonstrated afterwards. Build the minimum that works: a published address, a named owner, an internal deadline shorter than the legal one and a record with the date in and the date of the answer. That minimum already covers much of what the standard asks for in this domain. Then face the hard part, which is being able to locate a person's data everywhere it ended up.
50 to 79
Either the channel exists and the record is fragile, or the record is good and the channel is not public. In both cases the effect is the same: the company believes it responds well and cannot prove how long it took or what it answered. Standardise the record with the date of receipt, the date of the answer and a copy of what was sent, and make that apply to requests arriving through sales or support too, which is where most of them actually come in. With a low volume of requests, test with a simulated case instead of waiting for a real one.
80 or above
The process is built and recorded. What separates this band from the previous ones is the erasure request: locating the data subject in the main systems is common, finding them in a backup, a test database, a department spreadsheet and a third-party tool is rare. Do that exercise once, with a real data subject or a constructed case, and document where the data turned up. The result usually reopens the inventory, and that is what it is for.
Below 50
Privacy risk and security risk answer different questions, and where only the second exists the harm to the data subject never enters the calculation. Start small: pick the three processing activities with the greatest impact on people and write what would happen to them if the data leaked, were used for another purpose or could not be corrected. Record the decision on each one, even when the decision is to accept. It is that record, and not the sophistication of the method, that the auditor reads first.
50 to 79
The assessment exists and happens late. Privacy that arrives after the system is live becomes an expensive patch, and it is the pattern in a company that already has some security maturity. What closes that gap is not a new method, it is a trigger: a mandatory question in the project flow that identifies personal data before development starts. Include there the personal data going into artificial intelligence tools, today the most common route for processing nobody declared.
80 or above
The data subject risk assessment and the impact assessment happen at the right moment. What usually goes missing is the closing: an identified risk generates a decision, and a decision needs an owner, a deadline and a check afterwards. Look at reassessment as well, because a risk assessed once describes the project on the day it was born, and not the service it became. When the supplier, the volume or the purpose changes, the risk changes with it.
Below 50
Keeping everything just in case is the most common decision and the hardest to justify, because every piece of data without a deadline increases what can leak and what has to be found in an erasure request. Start with the retention table for the types you hold in the greatest volume, with the period written down and the reason beside it. Then deal with access, separating whoever consults personal data out of job need from whoever consults it as a leftover from an old position. The two items together reduce risk without requiring a large project.
50 to 79
The table exists on paper and the disposal does not happen. It is the most common gap in this domain, and the cause is rarely technical: what is missing is someone authorised to delete and a record that they did. Define who executes, how often, and keep the proof of disposal, which is the only evidence left afterwards. On access, what is almost always missing is the periodic review with a record of what was removed, and not the criterion for granting it in the first place.
80 or above
Retention and access are under control. Attention goes to the places where data reproduces itself without passing through the rule: a test environment populated from production, an export to a spreadsheet and a backup kept longer than the declared retention. None of the three is irregular in itself, and all three have to be written down and justified, otherwise the table says one thing and the environment says another. It is the inconsistency that shows up when the auditor asks to see, and not to read.
Below 50
Without knowing who handles personal data for the company there is no way to instruct anyone or to answer for anything. The list comes before the contract: payroll, cloud, marketing, collections, customer service and the subcontractor your supplier uses without telling you. With the list in hand, classify by criticality and start the contract review with the ones handling the most data or the most sensitive data. Reviewing everything with the same rigour is not sustainable, and the standard does not ask for it either.
50 to 79
New contracts go out with a clause and the old portfolio stayed as it was. Since the old contract is usually with the most entrenched supplier, that is where the largest volume of data sits. Use the renewal to revise and, where no renewal is near, use an addendum carrying the documented instructions. What is almost always missing too is the instruction itself: the clause says the supplier must protect, the instruction says what it may and may not do with the data, and it is the second one the standard asks of whoever contracts.
80 or above
The chain is mapped and contracted. What makes the difference from here is the follow-up after signature: periodic reassessment of the critical ones, a check that a new subcontractor was notified and an exit procedure that returns or deletes the data at the end of the contract. Termination is the most frequent blind spot in this domain, because nobody celebrates the end of a contract by checking what was left on the other side.
Below 50
This is the domain that least tolerates being compressed at the end, because internal audit, management review and handling findings only exist once they have happened, with a date. If there is a customer deadline on the table, this is where you start, even with the rest still under construction. On the incident side, the privacy-specific gap is who decides whether there was risk to the data subject and who notifies the regulator, a decision you cannot take on the day. Write that criterion down before you need it.
50 to 79
Either there is a security incident plan with no personal data angle, or there are follow-up meetings with no audit. They are different gaps with the same cause: privacy treated as a routine matter, and not as a system that gets verified. On the incident, add the data subject risk criterion and the notification deadline to the plan that already exists, instead of creating a parallel plan nobody will open. On the audit, the requirement that usually blocks is independence: whoever implemented cannot audit what they implemented.
80 or above
The cycle has closed at least once, and that is what most protects the programme over time. The point to watch is the effectiveness check: recording the corrective action is common, coming back months later to confirm that it worked is rare, and it is precisely what the auditor looks for when measuring maturity. It is also worth simulating a personal data incident end to end, including the decision to notify and the text that would go to the data subject, because the rehearsal reveals the delay the written process hides.
HOW WE RUN IT
The method is the one we use for ISO 27001, adapted to what privacy has of its own: the role in each processing activity, the legal basis and the data subject's rights. Led by an external specialist, with one focal point from your team, and each requirement assessed on a binary scale rather than a subjective score nobody defends in an audit.
We define the scope and boundaries of the management system (clause 4), engage leadership and set up the privacy governance (clause 5). In parallel we map the personal data processing activities and decide, activity by activity, whether the company is controller or processor.
Scope and boundaries of the management system approved
Inventory of personal data processing activities
Role defined per activity: controller or processor
Privacy governance in place, with the data protection officer formalised
MilestoneProcessing inventory approved and the role defined for 100% of the mapped flows.
We run the gap analysis against clauses 6 and 7, record the legal basis for each processing activity and assess the risks to the data subjects' privacy, which are not the same as information security risks. Where the law requires it, we produce the impact assessment.
Legal basis recorded for every processing activity
Assessment of risks to data subjects' privacy
Data protection impact assessment where applicable
Treatment plan and statement of applicability for the controls
MilestoneLegal bases approved by legal counsel and the treatment plan signed off by leadership.
We implement the Annex A controls matching the company's role, with the shared block serving both. This is the phase where handling data subject requests stops being improvisation: deadline, channel, record and a standard response, plus retention and disposal set by type of data.
Controller controls, processor controls or both, according to the role
A data subject request process, with deadlines and records
Retention and disposal policy by type of data
Privacy clauses reviewed in third-party contracts
MilestoneFirst cycle of data subject requests handled within the deadline and fully recorded.
We run the internal audit (clause 9) with a consultant independent of whoever implemented, conduct the management review and handle the findings (clause 10). We consolidate the evidence and stay with you through both stages of the external audit.
Internal audit run by an independent consultant
Management review, with findings addressed
Consolidated privacy evidence repository
Support through stage 1 and stage 2 of the external audit
MilestoneCertification audit completed and the certificate issued by the accredited body.
HOW LONG IT TAKES
We do not publish a standard timeline, because a published timeline becomes a promise. The spread is even wider here than for ISO 27001, for one specific reason: a company that ran a data protection project with method arrives halfway there, and a company that ran a paper project arrives at roughly zero. The first conversation already tells the two apart.
An up-to-date processing inventory and recorded legal bases take months off. A two-year-old report nobody maintained is usually worth less than it looks, and it is honest to say so before starting.
Being only a controller is the shortest road. Holding both roles across different flows multiplies the applicable controls and the contract clauses to revise.
With ISO 27001 or ISO 42001 in operation, clauses 4 to 10 are the same and much of the governance work is already done. With none, that base has to be built, and it can now be built directly on 27701.
THE ROLES ARE KEPT APART
As with every certifiable standard, the certificate comes from an accredited body you contract, never from DM11, and the clause 9 internal audit is run by someone who did not implement. There is a second separation here: the standard covers management and does not replace legal advice on data protection law. Both sides need to talk, and the project runs with a digital law specialist alongside the management specialist.
DM11 prepares, implements and supports. It issues no certificate
You contract the certification body, and the choice is yours
The clause 9 internal audit is carried out by someone who did not implement
The standard organises the management; interpreting the law stays with counsel
FREQUENTLY ASKED
The questions that come up in almost every first meeting, answered straight.
No, and that is the change that alters the maths. Up to the 2019 version, 27701 was an extension and could not be certified without 27001 in place. The revision published on 14 October 2025 made the standard self-contained: it no longer depends on implementing 27001 or 27002. If you received a proposal saying otherwise, it was written against the previous version. Holding 27001 still helps considerably, because clauses 4 to 10 are the same, but it stopped being a prerequisite.
No, and no standard does. Data protection law applies whether or not you hold a certificate; ISO 27701 is a management system that organises compliance and lets you prove it to third parties. In practice they support each other: a company that ran its compliance work with method arrives with much of the inventory and the legal bases ready, and a company that certifies first gains the maintenance discipline that usually goes missing once a compliance project ends.
Probably both, across different flows, and it is the first thing we settle. A controller decides about the processing; a processor processes on another company's behalf. A company is typically a controller of its own employees' data and a processor of the data it handles for customers. The standard splits the controls by role, so this definition is what most changes the size of the project.
Far less than starting from scratch. Clauses 4 to 10 are the same, so context, leadership, planning, internal audit and management review extend rather than duplicate. The new work concentrates on what belongs to privacy: the processing inventory, legal bases, data subject rights, retention and the Annex A controls matching your role.
It answers it well, and the standard was designed for that: it carries annexes mapping the controls to the GDPR. An internationally recognised certificate tends to end a conversation that a self-made dossier does not, because it came from an accredited third party. It does not replace contractual clauses or the international transfer analysis, which remain legal matters.
You will, as happened in the ISO 27001 transition from 2013 to 2022. The standard carries an annex mapping the new version against the 2019 one precisely to support that migration. The formal transition deadline is set by the international accreditation forum, and the last time we checked it had not yet been published. That is why there is no date here: when it comes out it becomes a fact and goes on the page.
No, and nobody who implements is allowed to. The certificate comes from an accredited certification body that you contract. DM11 prepares the company, implements the management system alongside your team and supports you through both stages of the external audit. It is the same separation that applies to ISO 27001, and it is what gives the certificate its worth.
Most data protection laws already require a controller to appoint one, so in most cases the role should exist before any certification. What the standard asks is that the responsibility be formalised and working, with genuine autonomy and a real contact channel. If your officer is internal and working alone, DM11's DPO Backoffice® exists for exactly that.
In the first conversation we look at what exists in terms of inventory, legal bases and the data subject request process, and tell you honestly whether the road is short or long.
ISO/IEC · ISO/IEC 27701:2025, edição 2, publicada em outubro de 2025 · accessed on
ISO/IEC · ISO/IEC 27001:2022, edição 3, com a emenda 1:2024 · accessed on
Presidência da República, texto consolidado · accessed on
This page is informational and describes how DM11 reads and applies the sources above. It does not reproduce the text of any standard, does not replace reading the official document, and does not replace an audit, a certification, an independent assessment or legal advice. Where a standard requires formal assessment, it is carried out by an accredited body, auditor or assessor, always separate from whoever did the preparation.