A statement of work crossed our desk last year with a line in the scope section that read, in full: “Automate the contract intake process.” No volumes, no definition of intake, no statement of where the process started or stopped. It had been signed by both parties.
That line is not unusual, and it is not really about contracts. It is about a category error that runs through most legal automation projects. “Intake” in that firm turned out to be seven separate waits: a business unit emailing a shared mailbox, someone opening the mailbox, someone deciding which reviewer it belonged to, the reviewer opening it, the reviewer asking for the missing counterparty details, the business unit answering, and the reviewer picking it up again. Almost none of the elapsed time was work. Nearly all of it was waiting for the next person to look.
That distinction decides which legal workflows are worth automating first, and it is the organising idea of everything below.
What intelligent automation means in legal work
Intelligent automation is the combination of three things that used to be bought separately. Rule-based automation, usually called RPA (robotic process automation), moves data between systems and performs deterministic steps. Document intelligence reads a file and extracts structured fields from it. A model, increasingly a generative one, drafts or classifies or summarises. Orchestration decides which of these runs, in what order, and when a human is required.
In legal work the useful framing is narrower than the vendor framing. Intelligent automation does not replace legal judgement, and any description of it that implies otherwise should be treated as a sales artefact. What it does is remove the steps between judgements: the routing, the chasing, the copying of the same eight fields into a third system, the assembling of the pack that a reviewer needs before the reviewer can think.
Two acronyms recur below and are worth fixing now. ESI means electronically stored information, the term the discovery process uses for anything that lives in a system rather than on paper. GAI means generative artificial intelligence, which is the term the American Bar Association uses in its ethics guidance, so it is the term used here when discussing that guidance.
Sort your use cases before you cost them
The six workflows legal teams usually shortlist are not one category. They divide cleanly by what is actually holding them up, and the division changes both the business case and the risk posture.
1
Queue-bound work.
The elapsed time is dominated by waiting for the next person to look at it. The work itself is short and largely uncontested. Automation here removes handoffs, and removing a handoff removes a wait, which is why the gain is large and shows up in days rather than minutes. Intake and triage, compliance evidence assembly, status communication to requesters and stakeholders, and matter reporting and billing preparation all sit here.
2
Judgement-bound work.
The elapsed time is dominated by someone reading carefully. Automation here does not remove the reading; it changes what the reader is given. That can be a real gain, but it arrives with a verification obligation attached, and the verification is new work that did not exist before. Substantive contract review and discovery review sit here.
The practical consequence is uncomfortable for pilot selection. Judgement-bound work is more interesting, demos better, and is what most vendors lead with. Queue-bound work is where the first measurable win lives. A programme that starts with contract review because it is impressive, rather than with intake because it is slow, tends to produce a well-received demonstration and no defensible number.
The four queue-bound candidates
Intake and triage.
A request arrives, and something decides what it is, whether the mandatory information is present, which reviewer or queue it belongs to, and what the counterparty and value bands are. Where information is missing, the requester is asked automatically rather than after a reviewer notices. This is the single highest-yield legal automation in most organisations and it involves no legal judgement at all.
Compliance tracking and evidence assembly.
Obligations with dates attached, and the evidence that each was met, collected as the work happens rather than reconstructed before an audit. GDPR is explicit that this is the controller's job rather than a nice-to-have: Article 5(2) states that the controller "shall be responsible for, and be able to demonstrate compliance with" the processing principles, and Article 30 sets out what the record of processing activities must contain and requires it to be made available to the supervisory authority on request.
Stakeholder communication.
The requester is told where their agreement is without anyone being asked. Most of the chase traffic in a legal inbox is not a request for work; it is a request for status, and status is a field, not a judgement.
Matter reporting and billing preparation.
Time, stage and volume data assembled into the shape the finance function and the client actually need, rather than reassembled by hand at month end.
The two judgement-bound candidates
1
Contract review support.
The system extracts the terms that matter (term length, renewal mechanics, liability cap, indemnity, governing law, termination triggers, data-protection clauses) and compares them against a playbook position. It does not approve anything. Its output is a reviewer’s starting position, which the reviewer then has to check, and the checking is real work. This distinction matters enough that it reappears in the model below.
2
Discovery support and legal holds.
Custodian identification, hold notices, acknowledgement tracking and volume reduction before review. It is worth being accurate about what the reference model here actually says, because the sequence is often described as a pipeline and it is not one. EDRM (EDRM.NET) states plainly that its diagram “represents a conceptual view of the e-discovery process, not a literal, linear or waterfall model”, that “one may elect to carry out the steps in a different order than shown here”, and that the process is iterative: “one might repeat the same step numerous times, honing in on a more precise set of results. One might also cycle back to earlier steps, refining one’s approach as a better understanding of the data emerges or as the nature of the matter changes.” EDRM adds that the diagram “is intended as a basis for discussion and analysis, not as a prescription for the one and only right way to approach e-discovery.”
That is not a pedantic correction. Automation designed around a linear pipeline breaks the first time a matter cycles back, and matters cycle back constantly. EDRM’s own definitions are worth keeping in front of the design: identification is “locating potential sources of ESI and determining its scope, breadth and depth”, preservation is “ensuring that ESI is protected against inappropriate alteration or destruction”, processing is “reducing the volume of ESI and converting it, if necessary, to forms more suitable for review and analysis”, and review is “evaluating ESI for relevance and privilege”. Three of those four are volume and custody problems. One of them is a judgement problem. Automate the three.
An illustrative model, in which touch time gets worse
The following model is illustrative. The structure and the arithmetic are real and reproducible; the inputs are stated assumptions rather than measurements from a specific engagement, and any team using it should replace every one of them with its own numbers before showing it to a finance function.
The workflow is one inbound agreement review request, of the NDA (non-disclosure agreement) and standard vendor paperwork type. The clock starts when the request arrives and stops when the agreement is returned or executed. A working day is eight hours.
Before. Seven queued handoffs. Median wait per handoff of four hours, which is half a working day, so a request that arrives in the morning is looked at in the afternoon. Ninety-fifth-percentile behaviour is not the interesting tail here; the ninetieth is, and at the ninetieth percentile the wait per handoff is 22 hours, or nearly three working days, because the reviewer is in a hearing or the requester is on leave. Human touch time across the whole request is 52 minutes.
That gives a median cycle time of 3.61 working days and a ninetieth-percentile cycle time of 19.36 working days. The queue accounts for 97.00 percent of the median. Fifty-two minutes of work is spread across three and a half days, and across nineteen days for one request in ten.
After. Intake, triage, routing and chasing are automated, which takes the queued handoffs from seven to three. Touch time does not fall to zero, and this is the part most business cases get wrong. It rises. The reviewer now confirms extracted terms instead of assembling them, which is 45 minutes rather than 52. Then a verification pass runs on every single request, without exception, at nine minutes. Then 18 percent of requests are routed to a closer second read at a further 15 minutes. Total touch time after automation is 56.70 minutes.
So the headline numbers move in opposite directions, and both belong on the same slide:
- Touch time per request: 52.00 minutes to 56.70 minutes, an increase of 4.70 minutes, or 9.04 percent.
- Median cycle time: 3.61 working days to 1.62 working days, a reduction of 1.99 days, or 55.16 percent.
- Ninetieth-percentile cycle time: 19.36 working days to 8.37 working days, a reduction of 10.99 days, or 56.77 percent.
- The gap between the median and the ninetieth percentile: 15.75 working days to 6.75 working days.
- Queue share of the median: 97.00 percent to 92.70 percent.
Across 2,880 requests a year (60 a week over 48 working weeks) the added touch time totals 225.60 hours. That is the honest bill. It buys back two working days on the median request and eleven on the difficult one, and it makes the difficult one less than half as far from the typical one, which is usually what a general counsel is actually being asked about.
Presenting it the other way round, as a reduction in effort, is the version that fails under examination. Anyone who then measures reviewer hours will find them up, conclude the programme was oversold, and be right.
The three breakevens that decide whether it holds
A model without its breakevens tells leadership what to hope for. Put the breakevens next to it and it tells them what has to be true.
Breakeven one: the queue has to be genuinely slow.
The whole gain comes from removing four waits, and it is paid for with 4.70 extra minutes of touch time. Those cancel out when the mean wait per handoff falls to 1.175 minutes. Above that, removing handoffs wins; below it, the extra verification effort buys nothing. That threshold is so low that it makes a useful point in the negative direction: in almost any legal function with a shared inbox, this trade is worth making. But run the sensitivity and the picture at the fast end changes character. At a mean wait of 240 minutes the median improves by 55.2 percent. At 120 minutes, 53.3 percent. At 60 minutes, 49.9 percent. At 20 minutes, 39.2 percent, and the absolute saving has collapsed to 0.16 of a working day. A team whose requests are already picked up within twenty minutes should automate something else.
Breakeven two: the removed steps must not come back as new steps.
Parity with the original 3.61-day median sits at 6.980 remaining handoffs. Start from the post-automation three and add queued review steps: one more takes the median to 2.12 days, two to 2.62, three to 3.12, and four to 3.62 days, which is worse than doing nothing. This is the most common way a technically successful legal automation produces no improvement anyone can feel. Verification becomes a queue. Exception handling becomes a queue. Approval of the automated output becomes a queue. Each is defensible on its own and four of them return the entire gain. Any design review should count the queues in the target state out loud, not the steps.
Breakeven three: coverage, not released hours.
There are no released hours here to realise, because touch time went up. What has to be realised is coverage: the share of requests that actually travel the shortened path rather than being pulled out of it because the counterparty sent a Word document with tracked changes, or because the requester emailed the reviewer directly. At 90 percent coverage the blended median is 1.82 days. At 75 percent, 2.12 days. At 60 percent, 2.41 days. At 40 percent, 2.81 days, and a 55 percent improvement has become 22 percent. To halve the median, coverage has to reach 90.65 percent. That number should be in the scope document, and the workflows that bypass the path should be named before go-live rather than discovered afterwards.
What safe adoption requires, specifically
Safe adoption in legal work is not a disposition, it is a set of documented positions. Four of them are load-bearing.
Human decision-making has to stay legally locatable.
GDPR Article 22(1) gives a data subject “the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her”, and Article 22(3) requires suitable safeguards including “at least the right to obtain human intervention on the part of the controller, to express his or her point of view and to contest the decision.” For most legal automation this is not triggered, because routing a contract to a reviewer produces no legal effect on anybody. For some of it, particularly anything touching claims, entitlements, employment matters or individual case outcomes, it is squarely engaged, and the position needs writing down by counsel in the design phase rather than argued about later. The test is whether a decision affecting a person is being made without a human in it, not whether a human is nearby.
Your automation vendor is a processor, and the contract has specific required contents.
GDPR Article 28 is prescriptive. The contract must set out “the subject-matter and duration of the processing, the nature and purpose of the processing, the type of personal data and categories of data subjects”. The processor must process personal data “only on documented instructions from the controller”. Article 28(2) prohibits engaging a sub-processor “without prior specific or general written authorisation of the controller”, and where the authorisation is general, the processor must inform the controller of intended changes and give it “the opportunity to object”. Sub-processor notification is the clause most commonly absent from automation and AI tooling agreements, and it is the one that matters most when a vendor changes its model provider.
Security is a documented and tested control set, not a certificate.
Article 32 requires measures appropriate to the risk, naming pseudonymisation and encryption, “the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services”, restoration of availability after an incident, and, the clause most often skipped, “a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.” Article 5(1)(f) sets the underlying principle of integrity and confidentiality, and Article 33 sets the 72-hour breach notification clock, which is an operational requirement on whoever runs the automation and not only on the security team. Article 32(3) notes that certification “may be used as an element by which to demonstrate compliance”, which is precisely the right weight: an element, not the demonstration.
Professional obligations do not move.
The ABA Standing Committee on Ethics and Professional Responsibility issued its first formal opinion on generative AI in legal practice on 29 July 2024, and the ABA’s own release sets out which of the Model Rules it says principally apply. Rule 1.1 on competence requires “legal knowledge, skill, thoroughness and preparation reasonably necessary for the representation” and, the release notes, that lawyers understand “the benefits and risks associated” with the technologies used. Rule 1.6 requires a lawyer using GAI to keep confidential all information relating to a representation “regardless of its source” absent informed consent, with similar protection extending to former and prospective clients. Rule 1.4(a)(2) requires the lawyer to “reasonably consult” with the client about the means by which the client’s objectives are pursued, which is the rule that decides whether a client needs telling.
The passage worth reading twice is the one on fees, because it is the closest thing to an authoritative ruling on the model above. The fifteen-page opinion notes, per the ABA’s release, that where a lawyer uses a GAI tool to draft a pleading and spends 15 minutes inputting the relevant information, “the lawyer may charge for that time as well as for the time necessary to review the resulting draft for accuracy and completeness. But, in most circumstances, the lawyer cannot charge a client for learning how to work a GAI tool.”
Read that against the model. The 561.60 hours a year of verification effort is review of output for accuracy and completeness, which the opinion treats as chargeable. The ramp-up, three fee-earners spending six hours each learning the tool, is 18 hours that generally cannot be billed to anyone. That is a ratio of 31.2 to 1 in favour of the chargeable side, which is a comfortable position, and it is only comfortable because verification was designed as a reviewable step on every request rather than as an informal habit. A verification pass that is not recorded is not obviously billable and not obviously happening. This is one place where the ethics requirement and the operational requirement point at exactly the same control.
The regulatory reasoning on why supervision itself gets harder is worth quoting rather than paraphrasing. The Solicitors Regulation Authority’s Risk Outlook report on artificial intelligence in the legal market, published 20 November 2023, puts it this way: “The speed that makes AI so useful can also make problems worse. Errors by an AI system could affect many more people than errors by a single person could… The high output of an AI system also makes it harder to supervise effectively.” It also names the confidentiality failure mode precisely, as “the output from an AI system replicating confidential details from one case in its response to another”, and forecloses the delegation argument: “you will remain responsible and accountable for the outputs from AI you are using. For example, if you use a third party chatbot to provide initial legal advice, you remain responsible for any errors in that advice.”
The report is now some years old and its adoption statistics are dated and, in its own words, reported secondhand, so it should not be cited as a picture of the current market. Cited for what it is, a regulator on the record about supervision and accountability, it has not aged at all.
The failure mode nobody instruments
Here is the mechanism that does the most damage, and it is not hallucination.
When a system extracts terms and compares them against a playbook, the reviewer’s job changes from constructing a position to agreeing or disagreeing with one. Agreeing is faster than disagreeing, because disagreeing means writing the alternative. Over a few months, the rate at which reviewers depart from the suggested position drifts down. Cycle time improves. Throughput improves. Every number on the dashboard improves. What has actually happened is that the playbook position is now being accepted in situations it was not written for, and the cost surfaces somewhere the automation programme is not measured: in amendments, in escalations during performance, in the commercial team relitigating a term nine months later.
How to detect it. Sample agreements that were executed through the automated path and check what proportion were amended, side-lettered or renegotiated within 90 days of signature, then compare that proportion against agreements executed before the change. If the automated cohort is amended more often, the improvement in cycle time is partly a transfer of work into the future rather than a removal of it. Track the reviewer departure rate from the suggested position as a series in its own right, and treat a falling series as a signal to investigate rather than as good news. A departure rate trending to zero means the reviewer has stopped being a reviewer.
The second detection method is cheaper and specific to generative output. Verify citations mechanically, not attentively. The AI Hallucination Cases database maintained by Damien Charlotin, updated 11 August 2026, records 1,870 identified cases in which a court or tribunal explicitly found or implied that a party relied on hallucinated content, with 1,558 involving fabricated material and 1,680 concerning case law. Two things about that dataset deserve stating rather than glossing. First, its own scope note: it tracks only decisions where the court made that finding, and “does not track the (necessarily wider) universe of all fake citations or use of AI in court filings”, and it describes itself as “a work in progress” while seeking to be exhaustive. So it is a floor, not a count.
Second, the party breakdown inverts the story the professional press usually tells. Pro se litigants account for 1,097 of the entries and lawyers for 725, with 27 involving judges. The dominant risk is therefore not principally that your own lawyers file a fabricated citation; it is that fabricated material is arriving at your organisation from the other side of a matter, from unrepresented counterparties, from claimants, and increasingly from opposing filings. An automation programme designed only to police its own output has covered the smaller half of the problem. The higher-value control is verifying inbound citations too, which is a mechanical lookup, which is to say it is exactly the kind of work that automates well.
The SRA report explains the mechanism in a sentence that is worth keeping in the design document, because it rules out the tempting shortcut: language models “work by anticipating the text that should follow the input they are given, but do not have a concept of ‘reality'”. The report’s own instruction follows from that, and it is unambiguous: “do not trust an AI system to judge its own accuracy”.
What it looks like when the ground moves
A global logistics operator running a European shared-services function came to us with a document-heavy workflow scoped, costed and agreed. Partway through delivery the upstream system it depended on changed: different fields, different structure, different behaviour on the exception path. The original design was, at that point, a correct solution to a problem that no longer existed.
What mattered was not the original architecture. It was that the workflow had been built so that the extraction layer, the routing rules and the exception handling could be changed independently, and that the exception path had been specified as a real destination with a named owner rather than as an error state. Re-pointing the extraction and adjusting the routing was a contained piece of work. Had the logic been a single monolithic sequence with exceptions treated as failures, it would have been a rebuild.
The reason this belongs in a legal article is that legal document workflows change underneath you more often than most. Playbook positions get revised. Templates get replaced. A new regulation adds a mandatory clause. A counterparty’s standard form changes. If the design assumes stability, every one of those events is a project. The question to ask of a proposed legal automation is not whether it handles today’s template, but what specifically has to be touched when the template changes, and who is able to touch it.
The renewal conversation
Most procurement advice concerns the questions to ask before signing, which is the conversation where a vendor is most prepared and you know least. The more informative conversation is the renewal, because by then you have a year of evidence and the vendor has a commercial reason to engage with it. Four things should be on that agenda, and agreeing them at the outset is what makes the renewal conversation possible at all.
Bring the coverage number, not the volume number.
Volume processed tells you the tool ran. Coverage, the share of in-scope requests that actually travelled the automated path, tells you whether it mattered. If the coverage figure cannot be produced, that is the first renewal finding.
Bring the queue count in the current target state and compare it to the one in the original design.
Every queued step added since go-live was added for a good reason and had a cumulative effect nobody costed. Four of them, on the model above, return the entire gain.
Bring the exception ledger and ask what changed in it.
Not the exception rate, which vendors will happily discuss, but the composition. A stable rate with a changing mix means new failure modes are appearing while old ones are being fixed, and the aggregate is concealing both.
Bring the sub-processor position and check it against Article 28(2).
Ask specifically which model providers and sub-processors were added or changed during the term, when you were informed, and whether you had the opportunity to object. If a model provider changed and nobody told you, the contractual failure is more consequential than any performance question on the agenda, and renewal is the last moment at which you have leverage over it.
A first workflow, chosen properly
Pick something that is high volume, low variation, queue-bound, and owned by a single team that can change how it works. Then instrument it for two weeks before touching anything, capturing four figures: the number of handoffs, the median wait at each one, the actual touch time, and the share of requests that bypass the standard path. Those four figures are the model. Without them, any business case is a set of assumptions wearing a spreadsheet.
Then build in the sequence that keeps the risk in front of you. Automate the intake and the routing first, because they contain no judgement and remove the most waiting. Add extraction next, with the verification step designed as a recorded action on every request rather than a habit. Define the exception path as a destination with an owner, not as a failure. Only then consider anything that touches judgement, and when you do, write down the Article 22 position and the client-communication position before the pilot rather than after it.
Where PAteam is usually useful is in the second half of that list rather than the first usually useful is in the second half of that list. Building an intake automation is not difficult. Building one that survives a template change, produces a coverage figure a finance function will accept, and leaves an audit trail that satisfies Article 30 is a different exercise, and it is mostly a question of how the exception path and the verification step were designed on day one. We work across intelligent automation, agentic workflows and contact-centre platforms agentic workflows, and in legal environments the pattern is consistent: the technology question is smaller than the design question, and the design question is smaller than the measurement question.
Frequently asked questions
Does intelligent automation reduce lawyer workload?
Often not, at least not at first, and a business case that promises it is fragile. In the illustrative model above, human touch time per request rises 9.04 percent because verification is new work. What falls is elapsed time: the median request completes 55.16 percent faster and the slowest tenth 56.77 percent faster. Legal automation is usually a cycle-time investment rather than a headcount one, and it survives scrutiny when it is presented that way.
Which legal workflow should be automated first?
The one where waiting dominates, not the one where reading dominates. Intake and triage is the usual answer: high volume, low variation, no legal judgement, and typically the largest number of removable handoffs. Substantive contract review and discovery review are more interesting and demo better, but automation there adds verification load before it removes anything, so they make poor first projects.
Is it safe to use generative AI on client matters?
It depends entirely on the controls, and the professional obligations do not change because a tool is involved. ABA Formal Opinion 512, issued 29 July 2024, identifies competence, confidentiality, client communication and fees as the model rules that principally apply, and the Solicitors Regulation Authority states that a firm remains responsible and accountable for AI outputs including advice delivered by a third-party system. In practice safe use means a recorded verification step on every output, a documented confidentiality position covering what the tool retains and what it trains on, and a written position on whether the client needs to be told.
Can we bill clients for time spent verifying AI-generated work?
ABA Formal Opinion 512 addresses this directly. Per the ABA’s own summary, where a lawyer uses a generative AI tool to draft a pleading and spends 15 minutes entering the relevant information, the lawyer may charge for that time and for the time needed to review the resulting draft for accuracy and completeness, but in most circumstances cannot charge a client for learning how to work the tool. The practical implication is that verification should be a defined and recorded step in the workflow, because unrecorded review is difficult to justify on a bill and difficult to prove happened.
What does GDPR require when a vendor runs our legal automation?
The vendor is a processor and Article 28 sets out required contract contents: the subject matter and duration, the nature and purpose of the processing, the categories of personal data and data subjects, and a requirement that the processor act only on documented instructions. Article 28(2) additionally requires prior written authorisation for sub-processors and, under a general authorisation, notification of changes with an opportunity to object. Article 30 requires records of processing activities available to the supervisory authority on request, Article 32 requires appropriate security measures including a process for regularly testing their effectiveness, and Article 33 sets a 72-hour breach notification deadline.
References
American Bar Association, “ABA issues first ethics guidance on a lawyer’s use of AI tools”, 29 July 2024. https://www.americanbar.org/news/abanews/aba-news-archives/2024/07/aba-issues-first-ethics-guidance-ai-tools/ Cited for the professional-conduct framework applying to generative AI in legal practice, specifically Model Rules 1.1, 1.4(a)(2), 1.5 and 1.6, and for the Rule 1.5 fee position on billing input time and review time but not tool-learning time. The full text of Formal Opinion 512 is served behind a challenge that blocks automated retrieval, so this article relies on the ABA’s own release, which quotes the opinion’s positions directly and is used only for what it quotes.
Damien Charlotin, AI Hallucination Cases database, last updated 11 August 2026. https://www.damiencharlotin.com/hallucinations/ Cited for the case count of 1,870, the nature breakdown (1,558 fabricated, 1,680 concerning case law) and the party breakdown (1,097 pro se litigants, 725 lawyers, 27 judges). The database’s own scope statement is material to how it is used here: it records only decisions in which a court or tribunal explicitly found or implied reliance on hallucinated content, it does not track the wider universe of fake citations or AI use in court filings, and it describes itself as a work in progress. It is therefore treated throughout as a lower bound rather than a total.
Solicitors Regulation Authority, “Risk Outlook report: The use of artificial intelligence in the legal market”, 20 November 2023. https://www.sra.org.uk/sra/research-publications/artificial-intelligence-legal-market/ Cited for the supervision passage (“the high output of an AI system also makes it harder to supervise effectively”), the accountability position that a firm remains responsible for AI outputs including third-party chatbot advice, the confidentiality failure mode of one matter’s details surfacing in another, the mechanical explanation of hallucination, and the instruction not to trust an AI system to judge its own accuracy. The report’s adoption statistics are not used: they are dated to end-2022, are prefaced in the report itself as reported secondhand, and its vendor-supplied performance figures carry no denominators or named datasets.
EDRM, “EDRM Model”, EDRM (EDRM.NET). https://edrm.net/wiki/edrm-model/ Cited for EDRM’s own characterisation of its model as a conceptual and iterative view rather than a literal, linear or waterfall process, for the statement that it is not a prescription for the one right approach, and for the stage definitions of identification, preservation, processing and review quoted in the discovery section. Content at edrm.net is licensed CC BY 4.0 with attribution to “EDRM (EDRM.NET)”.
Regulation (EU) 2016/679 (General Data Protection Regulation), official consolidated text on EUR-Lex. https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679 Cited for Article 5(1)(f) and 5(2) on integrity, confidentiality and accountability; Article 22(1) and 22(3) on decisions based solely on automated processing and the right to human intervention; Article 28 on processor contract contents, documented instructions and sub-processor authorisation; Article 30 on records of processing activities; Article 32 on security measures including the requirement for a process to regularly test their effectiveness; and Article 33 on the 72-hour breach notification deadline. The official text is used in place of third-party mirrors because on a regulatory claim the venue forms part of the evidence.
