What Article 29 GDPR requires from staff, contractors and processors
You must be able to show that every person with access to personal data, and every processor acting for you, handles that data only on your documented instructions. The risk Article 29 addresses is unauthorized or unlawful use of personal data by insiders and processors, whether that use is deliberate, careless or the result of someone doing a task they were never asked to do. Article 32(4) asks controllers and processors to take steps that ensure this, and Article 28(3)(b) requires your processor contracts to bind authorised persons to confidentiality or to an appropriate statutory duty of confidentiality. Together these provisions make the instruction limit enforceable through people, contracts and systems, not just policy text. The GDPR requires no audit, attestation or certificate for this duty. The organization owns it, and an implementation partner or assessor can help you prepare evidence but cannot carry the obligation for you.
The duty is hard in practice for three reasons. Access accumulates: people change roles, keep old group memberships and pick up administrative rights that nobody reviews. Instructions live in people's heads: the rules for what may be done with a customer record are rarely written down in a form an engineer, support agent or contractor can follow. Subprocessors multiply: each hosting, support or tooling provider adds another party who can reach the data, and each needs the same instruction and confidentiality terms flowing down from your contract. Decide who in your organization approves access to each personal data system, where the written instructions for each processing purpose live, and how you will learn when a processor believes one of your instructions infringes the GDPR, which Article 28(3) requires the processor to report to you immediately.
Start by listing every system that holds personal data and the roles that can reach it, then check whether each role has a written, current justification. Confirm that confidentiality commitments exist for employees, contractors and temporary staff, and that each processor contract contains the Article 28(3)(b) confidentiality wording. Keep dated training records that show staff were told what they may and may not do with personal data. Self-hosted platforms can help produce this evidence. For example, midPoint (EUPL-1.2+) access certification campaigns have designated reviewers decide within a set timeframe whether to keep, change or revoke access items such as role assignments, and Moodle (GPL-3.0-or-later) activity completion can record when a learner has viewed or been graded on required data protection training. Confirm both capabilities against your own configuration and the vendors' documentation before relying on them, for example in the midPoint access certification documentation and the Moodle activity completion API documentation.
Which people, systems and processors Article 29 reaches
Article 29 reaches anyone who can reach personal data under the controller's or processor's authority, which is wider than the employee list. Each category below changes who must be bound by instructions and confidentiality, and where the access evidence has to come from.
Employees with routine access
Staff whose job touches personal data need written confidentiality commitments, role-based access and training that covers the instructions they may follow. Check that HR onboarding, role assignments and access grants all point to the same record, so you can show who could reach which data on a given date. Access reviews should cover these accounts first, because they are the largest population and the most likely to accumulate rights over time.
Contractors and temporary staff
Contractors and agency workers often hold the same access as employees but sit outside the standard HR offboarding path. Confirm that each one is bound by a confidentiality obligation in their own contract or through the agency, and that the end date of that contract drives account expiry. Ask for evidence that access ended when the engagement did, not only that a contract was signed.
Administrators and break-glass accounts
Privileged administrators can read, copy and change personal data across systems, so they carry the highest risk of processing outside instructions. Break-glass accounts need documented triggers, named custodians, time-limited activation and a record of every use. Check that privileged sessions are logged and that someone outside the administrative team reviews those logs for purposes that were not authorized.
Processor personnel and subprocessors
Where a processor or subprocessor staff member can see personal data, the processor contract must require that those persons are under confidentiality duties and act only on the controller's instructions. Confirm which subprocessors have operational access, such as support engineers or managed service staff, and that the processor will tell you promptly if it believes an instruction infringes the GDPR. Keep the list of parties with access current, because it is the evidence an assessor will ask for first.
Production, backup and support copies
Personal data exists in more places than the production database: restored backups, exports attached to tickets, staging copies and log files. Each copy needs the same access restrictions as its source, or a documented decision that it is out of scope. Map where these copies sit and who can open them, since a backup restore administrator who can read live data is within Article 29 even if they never query the application.
Analytics and support tooling
Analytics platforms, ticketing systems and observability tools often receive personal data by default through event payloads, screenshots or pasted records. Identify which of these tools receive personal data, who administers them and whether vendor staff can access the content. Access evidence for these tools is frequently missing, so ask each team to show their user lists and role grants alongside the production systems.
How an assessor tests processing on instructions only
This table sets out what an assessor samples, what evidence they ask for, and where processing on instructions only tends to fail in practice. Read each row as a test step paired with the proof it needs, then check your own records against the same questions before an assessment begins.
| Test area | What the assessor samples or requests | Common finding |
|---|---|---|
| User accounts against HR and contractor records | A sample of active accounts with access to personal data, matched to current employment, contract end dates and role assignments | Accounts for leavers or contractors whose engagements ended months earlier and were never disabled |
| Access grants and approvals | Request tickets, approver identity and the business reason for each grant to systems holding personal data | Access granted by email or verbal request with no recorded approver or stated purpose |
| Periodic access reviews | Dated review records showing reviewers, decisions to keep, change or revoke, and follow-up on revocations | Reviews completed as a signature exercise, or reviewers who approve their own team's access |
| Shared and privileged accounts | Inventory of administrative and service accounts, named owners and evidence of individual logins or session logs | Shared administrator accounts used by several staff, so no individual can be tied to a processing action |
| Confidentiality commitments and contract clauses | Signed confidentiality agreements or employment terms for the sampled staff, and processor contract clauses requiring confidentiality of authorized persons | Contractors or temporary staff with system access but no signed commitment on file |
| Documented instructions | Written instructions from the controller to the processor and internal processing rules, with version history and approval records | Operational instructions given in chat or meetings and never recorded, so compliance with them cannot be shown |
| Notice of unlawful instructions | Records showing that staff or the processor raised instructions they believed infringed the GDPR, and how they were resolved | No escalation path exists, or the register of raised concerns is empty for a system with frequent change |
| Training completion records | Training content, completion dates and attendance for the sampled staff, with refresher cycles for those whose roles changed | Training completed at onboarding only, with no record for staff who moved into roles with personal data access |
| Processor contract terms | Processing agreements showing instruction-only processing, confidentiality of personnel and sub-processor flow-down | Contracts that omit the instruction-only obligation or cannot be produced for every processor in the sample |
| Access change after role moves | Sample of staff who changed roles in the period, with access before and after the move | Access accumulated across successive roles that is never removed, weakening segregation of duties |
How to implement instructions-only processing step by step
This sequence turns Article 29 from a policy statement into a working control: every person and processor with access is known, bound by confidentiality, limited to documented instructions, reviewed on a schedule, and able to flag instructions they believe infringe the GDPR. Each step closes with an artifact you can show an assessor.
Inventory everyone who can reach personal data
Build a register of every employee, contractor, service account and processor that can read, change or export personal data, covering both production and the copies held in backups, analytics stores and support tooling. Assign each entry an owner from the business side and a technical contact. Done means the register is complete enough that a system owner can confirm, system by system, who holds access and why. Reconcile it against identity provider groups and cloud IAM exports so that nothing is only known from memory.
Document written instructions for each processing purpose
For each processing purpose, the controller writes down the instructions that govern what the people and processors may do with the data, including permitted operations, recipients, locations, retention and prohibited uses. Processors receive these as part of their contract or a documented instruction set. Output: a versioned instruction document per purpose, approved by the controller and linked from the register in the previous step. Ask your legal or privacy lead to confirm that each instruction traces to a lawful basis recorded elsewhere in your GDPR documentation.
Bind each person to confidentiality in writing
Before access is granted, every person in the register signs a confidentiality commitment or confirms an existing statutory duty of confidentiality, and each processor's contract requires its authorized persons to be bound the same way. The commitment should state that data is processed only on the controller's instructions and that the duty continues after the role ends. Output: a signed commitment or contract clause on file for every entry, with a gap list that is zero before any access is provisioned.
Grant access by role with recorded approval
Define roles that map to the documented instructions, such as support agent, billing operator or database administrator, and grant access only through those roles. Each grant needs an approver who is not the requester, and the approval is stored with the ticket or identity record. Enforce multi-factor authentication for administrative and remote access where your risk assessment calls for it. Output: a role catalogue and an approval log showing who requested, who approved and when access was provisioned.
Configure periodic access certification campaigns
Schedule access certification campaigns in which designated reviewers decide whether each role assignment is kept, changed or revoked. Open-source identity governance tools such as midPoint support certification campaigns of this kind, but confirm the exact features and configuration with the project documentation for your version. Reviewers should have enough context to judge necessity, and revocations must flow back to the systems that hold the data. Output: campaign records showing reviewer decisions, completion status and the revocations actioned, retained as evidence.
Deliver role-based training on instructions and confidentiality
Train each role on the instructions that apply to its work, the confidentiality duty it has signed, and how to recognize a request that falls outside those instructions. Training should differ by role: a support agent and a data engineer face different situations. Learning platforms such as Moodle can record completion, but confirm how your configured activity completion conditions mark training as done, since completion can be triggered by viewing, grading or manual ticking. Output: completion records tied to role and course version.
Set up processor notice of possibly unlawful instructions
Write into each processor contract that the processor must inform the controller immediately if, in its opinion, an instruction infringes the GDPR or other data protection provisions. Define the channel, the named recipients and how the controller records its response. Test the path once with a tabletop exercise so both sides know who receives the notice. Output: the contract clause, a notice procedure with named contacts, and a record of the test and any notices received and resolved.
Keep the evidence current and reviewable
Assign an owner to keep the register, instructions, commitments, approvals, campaign records, training completions and notices in a single evidence set, and update it when people, processors or purposes change. Schedule a recurring check that compares the register with live access data, since drift between the two is the most common gap assessors find. Output: an evidence index that a reviewer can walk from any person with data access back to their instruction, commitment, approval and latest review.
How midPoint and Moodle can produce access and training evidence
midPoint is an open-source identity governance and administration platform licensed under EUPL-1.2+. Its access certification feature runs campaigns in which designated reviewers look at access items, such as role assignments, and decide within a set timeframe whether to keep, change or revoke each one. Access rarely shrinks on its own: people move teams, pick up extra roles and keep old ones, and over time they accumulate rights they no longer need. A recurring review campaign creates a dated record of who reviewed what, what they decided and what was changed, which is the kind of record an assessor will ask to see when testing whether access to personal data is limited to what instructions require. Campaigns also help expose combinations of roles that break segregation of duties, such as one person being able to both request and approve a data export.
- Reviewer assignment: Define who reviews each access item, usually the line manager or the owner of the system, and record that ownership before the first campaign runs.
- Decision timeframe: Set a deadline for each campaign so that undecided items are handled by a defined rule rather than left open.
- Revocation trail: Confirm that revoked assignments are removed from the connected systems, not only from the identity store, and keep the campaign output as evidence.
- Segregation of duties review: Use reviews to check that no single identity holds conflicting roles over personal data.
- Scope of connected systems: Confirm which applications and directories feed midPoint, because access granted outside it will not appear in a campaign.
Before relying on this feature, confirm with your platform team how midPoint fits your identity architecture, including which directories and applications it reads from and writes to, and whether your existing single sign-on and privileged access tools overlap with it.
Moodle is an open-source learning management system licensed under GPL-3.0-or-later. Its activity completion feature marks an activity as complete for each learner when they view it, when they receive a grade from it, or when they tick it manually, depending on the conditions set for that activity. Used this way, Moodle can hold the training records that show staff and contractors with access to personal data were told their processing must follow the controller's instructions and were bound by confidentiality. It turns a policy acknowledgement into something with a timestamp and a named learner, which is far easier to produce during an assessment than a folder of signed forms.
- View-based completion: Use it for reading a policy or a privacy notice, but recognize that opening a page does not prove the content was understood.
- Grade-based completion: Attach a short quiz to the module so completion depends on a passing score, which gives a stronger record of comprehension.
- Manual completion: Reserve it for signed acknowledgements of confidentiality terms, and pair the tick with a stored copy of the signed text.
- Completion reports: Export records for every person with access to personal data and reconcile them against the access review output from your identity system.
- Refresher cycles: Reassign training when policies change or when people change roles, and record the reassignment.
Completion records are only as good as the conditions behind them. Check which conditions each activity uses, who can edit those settings, and whether completions survive course resets, before you present them as evidence.
Evidence that shows staff and processors act only on instructions
Article 29 and Article 32(4) are tested through records, not statements of intent. The artifacts below show who may process personal data, on what instructions, how that access is granted and reviewed, and how confidentiality and training are enforced. Each one should be kept current between audits so the evidence reflects the systems as they run today.
Documented processing instructions per purpose
Written instructions tell staff and processors what they may do with personal data for each purpose, such as which fields a support team may view or which jobs may export records. An assessor checks that each instruction traces back to the controller, that it is specific enough to test against system behaviour, and that the people with access can be matched to it. Review the instructions whenever a purpose, system or processor changes, and record the date and approver of each revision. Also check that the process for a processor to flag an instruction it believes infringes the GDPR is written down and used.
Access request and approval records
Each grant of access to personal data should have a request, a stated business reason tied to an instruction, an approver who is not the requester, and a timestamp. An assessor samples accounts and asks who approved them and against which instruction. Keep these records in the identity or ticketing system for as long as the access exists and for a period your retention policy sets. Confirm with your own legal and HR teams how long these records must be held.
Periodic access review outcomes
Access accumulates as people change roles, so reviews are what stop users from keeping rights they no longer need. Access certification campaigns, such as those in midPoint, have designated reviewers decide within a set timeframe whether to keep, change or revoke each access item. An assessor looks for completed campaigns, the reviewer named on each decision, revocations that were actually carried out, and the cadence agreed in policy. Confirm the review frequency with your own risk assessment rather than adopting a default.
Signed confidentiality commitments
Article 28(3)(b) expects persons authorised to process personal data to have committed to confidentiality or to be under an appropriate statutory duty of confidentiality. Keep signed employee and contractor commitments, and for processors, the contract clause that binds their personnel. An assessor checks that every account with access to personal data maps to a current commitment and that leavers are linked to a revocation. Ask your HR and legal teams to confirm the wording used in your jurisdictions.
Training completion records
Training shows that people who can reach personal data understand the instructions that govern them. Learning platforms such as Moodle can record completion when a learner views an activity, receives a grade or ticks it manually, depending on how the activity is configured. An assessor expects the completion condition to match the policy, for example a graded assessment rather than a click-through. Compare training lists against the access review population at least as often as reviews run, and confirm the completion rule with your own course configuration.
Processor contract clauses and instruction-conflict notices
The processor contract should require processing only on documented instructions and require the processor to inform the controller immediately if it believes an instruction infringes the GDPR. An assessor looks for that clause in every processor agreement, the sub-processor flow-down, and any notices actually received and how they were resolved. Keep the executed contracts and notice log together, and review them when a processor changes its services. Have counsel confirm the clause language against Article 28.
What meeting Article 29 costs in money and effort
This table lists the cost components of making Article 29 enforceable, who typically carries each one, whether it is one-time or recurring, and what moves it up or down. Use it to structure a written quote, since no supplied figures exist for these costs and every amount depends on your own scope.
| Cost component | Who is paid or who spends time | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Role design and access tooling | Internal engineering and identity staff, plus any implementation partner for fixed-scope work | One-time, with later revisions when roles change | Number of systems holding personal data, number of distinct roles, and whether identity sources are already integrated |
| Confidentiality and processor clauses | Internal legal or privacy counsel, and outside counsel where contracts are negotiated | One-time per template, recurring per new staff contract or processor | Number of processors and contractors, how many jurisdictions apply, and whether standard templates already exist |
| Training content and delivery | Internal privacy team to write content, learning platform administration, and staff time to complete it | Content one-time, delivery and refresh recurring | Headcount, staff turnover, contractor volume, and how often instructions or systems change |
| Recurring access reviews | System owners and designated reviewers who decide whether to keep, change or revoke access | Recurring, usually on a set cycle | Number of role assignments, number of systems in scope, and how quickly joiners, movers and leavers are processed |
| Evidence upkeep | Compliance or security staff who collect logs, review records and approvals, and store them | Recurring | Log retention needs, number of evidence sources, and whether collection is automated or manual |
| Open-source platform licensing | No license fee for the open-source components named on this page, subject to each project's license terms | Recurring only if paid support is bought | Choice of support tier, if any, and whether internal staff can operate the platform |
| Deployment and maintenance of open-source tooling | Internal platform engineering, or an implementation partner under a written scope | Deployment one-time, upgrades, patches and backups recurring | Number of environments, high availability requirements, integrations with HR and directory systems, and upgrade cadence |
| External testing of access controls | Independent security testers, scoped separately from the platform build | Usually periodic | Number of applications and APIs in scope and whether testing covers privileged access paths |
| Auditor sampling | Independent auditor or assessor, who selects samples and tests evidence | Recurring at each audit cycle | Population sizes to sample, quality of evidence on first request, and number of systems the auditor must examine |
Who owns Article 29 work, and what a partner can take on
Your organization owns the legal and operational decisions that make Article 29 enforceable. Your controller or processor role determines who writes the instructions, who approves access, and who signs the confidentiality commitments that staff and contractors make. A partner can help draft the materials, but the instructions and the access decisions remain yours.
- Written instructions: Define which processing each role may perform, with purposes and data categories, and keep them current when systems change.
- Access decisions: Decide who needs each permission, approve exceptions, and name the reviewers who recertify access on a schedule you set.
- Confidentiality commitments: Obtain signed confidentiality undertakings or confirm statutory duties for employees, contractors and any sub-processor personnel.
- Training content: Own the policy on what staff must learn before access is granted and what they must repeat afterward.
- Incident and instruction escalation: Decide who receives a processor's notice that an instruction appears to infringe the GDPR, and how you respond.
Before engaging anyone, confirm internally that each of these owners is named in writing and has the authority to approve changes.
An implementation partner such as DeployOpen can prepare the technical controls that enforce your instructions inside your own infrastructure. The partner works under a written, fixed scope and does not decide what data may be processed or who should be granted access. Its output is configured systems and collected evidence, which you review and accept.
- Identity and access configuration: Set up directory integration, role models and segregation of duties in the platforms you self-host.
- Access certification workflows: Configure recurring review campaigns, for example with midPoint's access certification features, so designated reviewers can keep, change or revoke items.
- Training workflows: Build confidentiality acknowledgment and training courses, for example with Moodle activity completion, so completion records can be retrieved.
- Evidence collection: Export access logs, review decisions and training records into a format your assessor can sample.
- Documentation and hardening: Write runbooks for the configured workflows and keep them aligned with the platform upgrades.
Ask the partner to state in the scope which items it configures and which items remain your responsibility, and confirm that it will not approve its own reviews or sign off its own evidence.
An independent auditor or assessor tests whether the controls operate as described and reports the results. Only that party issues an attestation, report or certificate. The GDPR itself requires no audit, and Article 42 certification is voluntary and issued by accredited bodies or supervisory authorities, so any assessment you commission is evidence for your own accountability rather than a legal stamp.
- Independence boundary: The auditor must be separate from the party that configured the systems, so the partner cannot test or attest to its own work.
- Sampling: Expect the auditor to select users, review decisions and training records and trace them back to written instructions.
- Reporting: The auditor, not DeployOpen or any other implementer, issues the findings and any report.
- Scope agreement: Confirm in writing which processing activities, systems and periods the assessment covers.
- Remediation tracking: Your team decides on corrective actions, and the implementer may build fixes that the auditor then retests.
Before hiring an assessor, confirm its independence from your implementation partner and ask how it will document its sampling method.
Some Article 29 work is practical to outsource and some must remain with accountable staff. The split depends on your size, internal skills and how much configuration effort the platforms require. Use the list below as a starting point for a scoping discussion, not as a legal allocation.
- Usually outsourced: Initial configuration of identity and access tooling, building review campaigns, creating training course structures, and exporting evidence.
- Usually outsourced: Penetration testing or independent assessments of the configured controls, performed by a party that did not build them.
- Must stay in-house: Writing and approving processing instructions, deciding who receives access, and signing or managing confidentiality obligations.
- Must stay in-house: Receiving and acting on processor notices about unlawful instructions, and running ongoing access reviews as the accountable reviewers.
- Shared: Maintaining training content and runbooks, where the partner drafts and your owners approve each revision.
Ask any partner to put this split in its written scope so responsibilities are visible before work begins.
Where organizations fall short on instructions-only processing
Most organizations have a written rule that staff process personal data only as instructed. The gaps appear in how access is granted, reviewed and tied to confidentiality and training. The cards below cover the places where that rule stops being enforceable in practice.
Shared administrative accounts
When several engineers log in with one administrator account, no system record shows who changed a database, exported a dataset or altered a retention setting. Under Article 29, the controller cannot show that a named person acted only on instructions. Give each administrator a personal account, require multi-factor authentication, and check that privileged actions appear in logs under individual identities.
No owner for access reviews
Access tends to accumulate as people change roles, and nobody is responsible for removing what they no longer need. Assign a named reviewer for each system holding personal data and set a review date. Campaign tools such as midPoint's access certification let designated reviewers keep, change or revoke role assignments within a set timeframe, which gives you a dated record of each decision.
Contractors with standing access
Contractors and consultants are often given broad, permanent access because it is faster than requesting it each time. Standing access outlives the engagement and the contract that bound the person. Grant time-limited accounts tied to a ticket or statement of work, remove them at the end date, and confirm the removal in the access review record.
Temporary staff without confidentiality terms
Agency workers, interns and short-term hires frequently start work before a confidentiality undertaking is signed, or sign a generic form that does not cover personal data. Make a signed confidentiality commitment a precondition for account creation. Keep the signed record with the access grant so that an assessor can match each person with a commitment.
Training not linked to access
Annual awareness training is often completed by everyone except the people who most need it, and completion is rarely checked against who can open a sensitive system. Tie data protection training to the role that grants access, and block access until the required module is complete. Moodle's activity completion can record when a learner has viewed or finished an activity, which gives you a per-person record to match against access grants.
Processors without an instruction-conflict duty
A processor that believes an instruction breaks the GDPR must tell the controller immediately, but many service contracts are silent on this. Without the duty, a processor may carry out an instruction it doubts, or stay quiet. Add a clause requiring prompt notice of any instruction the processor considers unlawful, name the contact who receives it, and log the notice when it arrives.
Questions buyers ask about Article 29 GDPR
How much effort does Article 29 compliance take, and what drives it?
Effort depends mainly on how many people and systems can reach personal data, and how far that access already matches business roles. Article 29 does not set a number of hours or a budget. The work has three parts: mapping who can access personal data, tying each person's processing to written controller instructions, and keeping confidentiality commitments and training current. Organizations with many roles, shared accounts, contractors and multiple processors usually need the most work. Ask any partner for a fixed-scope written proposal that lists the systems in scope, the roles reviewed, the training modules produced and the evidence delivered. Costs recur when staff, contractors or processors change, so ask what the handover and periodic review look like.
Can our organization meet Article 29 without outside help?
Yes, in principle. The GDPR does not require an external provider, and the controller or processor remains responsible for compliance. Internal teams with access to identity systems, HR records and legal counsel can define instructions, confidentiality terms and training. Outside help is most useful when access sprawl is large, when role data is spread across several platforms, or when staff lack time to run structured reviews. An implementation partner can prepare systems and evidence, but it cannot decide what your instructions are or certify your compliance. Confirm with your data protection officer or counsel which decisions must stay in-house.
How long does setup usually take?
No researched figure supports a general duration, so treat any timeline as unverified until it is written into a scope. The main variables are the number of identity sources, the state of existing role definitions, how many personal data systems exist, and whether confidentiality agreements already cover all staff and contractors. Ask a prospective partner to split the timeline into discovery, access mapping, remediation, training rollout and evidence collection, and to state which items depend on your teams' availability. Ask your own legal and HR teams how long they need to update contracts and policies.
What does the work need from our team?
Expect to supply people who can answer four questions: who needs access to personal data and why, which written instructions govern each processing activity, which staff or contractors have signed confidentiality commitments, and who approves access changes. In practice this means system owners for identity, HR and each application holding personal data, plus legal or privacy staff who own the instructions. A processor must also be able to tell the controller when an instruction appears to breach the GDPR, so the team needs a named route for that notice. Agree these owners in the written scope before work starts.
Will the evidence a partner produces satisfy an auditor?
A partner can prepare evidence, but only an independent auditor or assessor decides whether it is sufficient, and the GDPR itself requires no audit or certificate. Useful evidence includes role and access exports, documented access review decisions with reviewer names and dates, signed confidentiality commitments, training completion records and the written instructions that link processing to purpose. Ask the auditor or your regulator contact which formats they accept before the work is designed. Certification under Article 42 is voluntary, and a certificate does not reduce your responsibility for compliance.
Does self-hosting change the Article 29 duty?
Self-hosting does not remove the duty. Article 29 applies to anyone with access to personal data, whether the platform runs in a public cloud, your own data center or an air-gapped network. Self-hosting can make the duty easier to enforce because you control the identity provider, the access review tooling and the logs. For example, an illustrative deployment might use midPoint access certification campaigns to have designated reviewers keep, change or revoke role assignments, and Moodle activity completion to record that staff have viewed training. Confirm that each tool's capabilities match your evidence needs before relying on them, and check the GDPR text with counsel.
How DeployOpen works on this
DeployOpen plans, implements and hardens self-hosted open-source platforms inside your own infrastructure, so the access controls, confidentiality commitments and training records that support Article 29 can be built into the systems you run. We prepare the systems and evidence; your organization owns its controls, and an independent auditor or assessor forms any conclusion about them.
How we scope
- Map every system, role and group that can reach personal data, including staff, contractors and processors.
- Record which processing instructions each role must follow and where those instructions are written down.
- Agree the scope in writing before work starts, with deliverables and timelines fixed in the statement of work.
How we build
- Configure role-based access so each role grants only the personal data access it needs for its instructions.
- Set up access certification campaigns in the identity platform so designated reviewers keep, change or revoke access.
- Wire confidentiality acknowledgements and role-specific training into the platforms your staff already use, with completion records kept.
How we hand over
- Document the access model, reviewer assignments and certification cycle in a handover pack your team can maintain.
- Export access review records, training completion logs and configuration evidence in formats your assessor can inspect.
- Walk your compliance and security leads through each evidence item so they know what it shows and what it does not.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
- Confirm with your legal counsel and assessor how instructions, confidentiality terms and processor contracts should read for your processing.
- Review access models again when roles, processors or platform versions change, and record each change in the evidence file.
