DPIA as a Genre, Not a Form

The EDPB template dropped publicly last week. I opened it for the first time on the train between Pescara and Rome — a PDF of about forty pages that felt familiar before I’d even read it, read with that particular distracted attention one reserves for documents one already knows everything about. I’ve been living with the DPIA for years, helped write dozens of them, grown accustomed to treating it as a stable object: a form, a checklist, a compliance artefact to hand to the DPO and file away. Opening the new template, I had in my hands something familiar and slightly altered, the way it feels to return to a flat you lived in as a young person and discover someone has moved the furniture without telling you. Something irritated me, and I couldn’t name it.

It was only a few days later, reading it calmly at my desk, that I understood what had been bothering me. The template wasn’t a more detailed version of the previous one. It was something else. Not an improved form, not a finer grid: the document in my hands demanded something different from whoever filled it in and, more subtly, demanded something different from whoever read it. The DPIA was ceasing to be a form and turning into — to borrow a term I spent my university years chewing over — a genre.

What has arrived, and what hasn’t

It’s worth stating straight away what has and hasn’t arrived, because the nuance matters for the rest of the argument. The EDPB adopted the template in version 1.0 by written procedure on 10 March, released it publicly in April alongside an explainer document accompanying each section, and opened it to public consultation until 9 June. The template’s use is not mandatory: controllers may continue to use whatever DPIA methodologies they prefer. After the consultation, and with whatever revisions are made, every national data protection authority will take steps to adopt it either as its own standard or as a meta-template with which national models will have to align. Nothing is yet closed, in short, but everything is taking shape — and the shape it’s taking is precisely what I want to discuss here.

I’m aware I have to argue against the common intuition. Most people working with DPIAs treat them as bureaucratic bother, a burden to dispatch, a piece of paper the legal consultant fills in and the client archives. In Italy, where compliance has long kept a defensive profile, DPIAs have often been written not to be read, and read not to be discussed. The question «what do you actually need from a well-done DPIA?» tends to yield practical answers: that it be complete, cover the use cases, not contradict other documentation, survive an authority’s inspection. These are honest answers. They are also, I’d argue, the wrong ones — or rather, they are the answers one gives if the DPIA really were a form. And that is precisely what, until a few weeks ago, the DPIA still was across much of Italian practice. An author-less document in the weakest sense: someone signed it, yes, but no one took responsibility for it in an editorial sense.

A template is not a form

But here we reach the point. A template is not a form. A template, the moment it is proposed by an authority like the EDPB with the explicit ambition of becoming the common European standard, ceases to be a filling-in instrument and becomes something stranger and more powerful: the codification of a form. And a form is not filled in. A form is written, and it’s written with full awareness of being read within specific expectations, with a lexicon, a narrative structure, a rhetorical rhythm that are not interchangeable with others. That, in short, is a genre.

To see why the shift matters, it helps to step back and look at how the DPIA got here. It has existed formally since 2018, mandated by Article 35 GDPR as a required assessment for high-risk processing. In the early years it was handled as it could be handled: each organisation, each law firm, each DPO produced its own version, with a variability anyone who’s worked cross-sector knows well. Some DPIAs were five-page documents that read like meeting minutes; others were hundred-page tomes that read like doctoral theses. Some were compiled with numerical risk matrices inherited from security frameworks, others in dense legal prose laden with normative references, still others with hybrid approaches that mixed the two cultures without quite making them cohabit. The Commission had suggested certain outlines, first Working Party 29 and then the EDPB had published guidelines, some national authorities had made more structured models available, but the landscape remained fragmented. The DPIA sat in that state of a young thing whose forms haven’t yet settled, where everyone tries their own path and few of those paths meet. European supervisory authorities had complained repeatedly about this heterogeneity, which made it hard to build the kind of implicit, shared jurisprudence every mature field builds by reading hundreds of documents produced according to a recognisable form.

When a form takes shape

The EDPB template opens the closure of this phase. Not with the formal authority of a binding regulation, which it is not, but with something like the authority a normative grammar exerts over a living language: it indicates, orients, creates a centre of gravity. From now on, anyone writing a DPIA in Europe knows there is a form proposed at the supranational level, and knows that when the consultation closes and national authorities have taken their adoption steps, every deviation from that form will require justification. This is exactly, in the history of languages and literary genres, the movement by which a form takes shape. Before Dante, Florentine vernacular was one of many Italian vernaculars; after Dante, every use of Florentine vernacular measured itself against him, even when it wanted to move away. Comparing Dante to a bureaucratic template is disproportionate, I know. I leave it anyway because the mechanics are the same, even if the altitudes are obviously incomparable. When an authority proposes a form and all the authorities beneath it announce they will adopt it, that form ceases to be one possibility among many and becomes the background against which all the others stand out.

Architext and self-inquisition

Literary scholars call this phenomenon the stabilisation of an architext, a term I owe to Genette but which was already circulating in Bakhtin under the name secondary speech genres. The architext is not a single work: it is the set of formal expectations a reader brings to a certain type of document. When I open a detective novel I know there will be a crime to solve; when I open a scientific article I know there will be a methods section; when I open a sonnet I count the lines before reading them. A stabilised architext produces stabilised expectations. And it produces, inevitably, a form of writing that knows it is being read within those expectations. Hans Robert Jauss, from 1970 onwards, called this reader’s stance — encountering a text within an already known genre frame — horizon of expectations. For Jauss, every text is read twice: once against the frame the reader brings, once reshaping that frame according to what the text actually says. A DPIA written inside the EDPB template, once that template has become the reference standard, will be read this way: the auditor or inspector will already know what to look for, in what section to expect what, will recognise immediately when the text departs from the expected form, and will construct a judgement from that deviation.

There is a second theoretical thread I want to invoke, because it illuminates the point in a different direction. Carlo Ginzburg, in his work on the sixteenth- and seventeenth-century inquisitorial trials of Friuli, showed how the transcripts of those trials were a genuine documentary genre, with precise rhetorical conventions, a coded relation between interrogator and interrogated, a particular handling of voice between direct and indirect discourse, a narrative structure that translated the defendant’s voice into the inquisitor’s procedural frame. Ginzburg read those transcripts as texts, not as pure transcriptions, and in that reading found traces of a popular subjectivity otherwise invisible. Beyond the historical comparison, there is a structural analogy that has struck me since I started thinking about the DPIA. A DPIA is, in its deep architecture, a self-inquisitorial document: the controller interrogates itself about its own conduct, reconstructs the reasons for its choices, argues before an absent but threatening reader (the authority) why those choices are adequate. It is a form of discourse that exposes its own rationality in order to be judged on it. The fact that it now has a template destined to become a codified genre means, among other things, that this self-inquisition is about to have a grammar. And grammars, as anyone who has studied them seriously knows, are not neutral instruments: they model what can be said, and indirectly what can be thought.

The window of canon formation

Anyone writing a DPIA in the coming months finds themselves in a particular position, different from both the pioneer’s and the practitioner-inside-a-mature-genre’s. The template is on the table but isn’t yet a standard, the consultation is open, national authorities are preparing their transposition steps. Writing a DPIA in this window means writing inside a form that is still stabilising, which means two things. First, one can no longer behave as a pioneer: the template is available, its sections are clear, its method is public, ignoring it would be a deliberate gesture that needs motivation. Second, less obviously, there is an opportunity that writers two years from now won’t have: the chance to contribute, through one’s practice, to defining what «writing well» will mean inside this genre. Every DPIA produced now that engages seriously with the template, that uses it as structure, that flags its limits, contributes to forming the canon. In stabilised genres the canon already exists; in forming genres the canon is made by writing it. For those of us who do this work, it’s worth being present precisely in this window.

From form to prose

It could be objected that I’m romanticising what is merely a longer form. The objection is serious and deserves to be taken seriously. If the DPIA were only a longer form, its evolution would be irrelevant outside the narrow perimeter of compliance: another grid to fill, another kind of PDF to archive, another marginal cost for those processing data. But there’s a detail in the new template that, once noticed, dismantles this reading. The template no longer asks merely to list. It asks to argue. It asks, in particular, to justify the proportionality of choices, to reconstruct the reasoning that leads from a risk assessment to a mitigation measure, to show why a given balance between utility and residual risk is acceptable. It asks, in short, something a form cannot ask: it asks for prose.

The appearance of prose in a compliance document is the clearest symptom of the shift to genre. A form doesn’t need prose, because its informational value is entirely contained in the grid. A genre, by contrast, lives in prose, because it is in prose that connections between facts, hierarchies of importance, justifications, and nuances are expressed. When the EDPB template asks you to write why the chosen legal basis is adequate to the context of the processing, it is asking for a small essay. The content of that essay will have formal constraints, but it remains an essay. And whoever writes an essay — even a three-hundred-word essay in a PDF box — writes differently from whoever fills a cell in a spreadsheet. Prose forces a point of view, forces decisions about what comes first and what comes later, forces showing which information is accessory and which is central. The grid, by its nature, flattens these hierarchies. The shift from grid to prose is not a shift of pure form; it is a shift of local epistemology, of what a given text can tell and what it cannot.

The many readers of a DPIA

An underrated aspect, and one I want to bring to light, concerns who actually reads a DPIA. Current practice almost always imagines a single reader, or rather a hypothetical, under-characterised one: the inspector from a supervisory authority — a somewhat abstract figure most DPIAs will in fact never meet. But a document of genre always has more real readers than it declares, and the DPIA is no exception. The public buyer assessing a vendor reads it. The compliance officer doing due diligence on an acquisition reads it. The lawyer preparing a defence in litigation reads it. The data subject who wants to understand how their data is processed reads it — if it is well written and made accessible. Increasingly, the upstream technology vendor who needs to verify whether its processor role has been correctly scoped reads it. Each of these readers brings a different horizon of expectations, and the fact that the EDPB template is stabilising the form helps all of them at once: a disciplined reader knows where to look, knows how to recognise what they’re looking for, can distinguish a well-made text from a botched one. A form is ultimately opaque to any reader external to its filler. A genre, by contrast, has the democratising virtue of being legible to anyone who knows its conventions.

DPIA-as-code

Let me return for a moment to Oltrematica’s experience in recent months, because it was exactly the day-to-day of certain projects that made me understand what was changing. We have ongoing work on healthcare platforms for the Abruzzo region, on people analytics systems in hospital settings, on applications for local public administration, on online training platforms with ECM certifications, on parking management systems for municipal utilities. In every one of these cases we have, or will have, a DPIA. Until a year ago the typical approach was: set up a call with the client’s DPO, gather information, produce a draft, review it together, put it in the repository. The document was essentially closed at the end of the process. It was updated when processing changed, on an annual or biennial review cycle. It was, clearly, a form. What’s interesting is that internally within the tech team we also treated the DPIA as a form: we considered it something the DPO produced for us, not with us, and that concerned us only if an auditor asked us to confirm some of its contents.

When I read the new template, the first thing I did was write an internal memo about what would change operationally. The second, less immediate, was to draft a proposal I briefly called DPIA-as-code: bringing the DPIA inside the project’s versioning flow, integrating it with Jira and Confluence, making it an artefact that lives in the same ecosystem as the code. It isn’t a revolutionary idea. Others were already thinking along these lines, particularly in environments where compliance has historically been entangled with software engineering — I’m thinking of certain security teams in the US cloud-native world. But the reason the proposal makes sense precisely now, and not two years ago, is exactly what I’m writing about: only when a document is becoming a genre, and no longer a form, does it make sense to version it the way you’d version a chapter of a book. A form is updated with a new form; a chapter is revised with genetic traceability, attention to variants, an archive of decisions that lets you retrace your steps and understand why, a year ago, you chose a certain phrasing over another.

The projects where this transformation is proving most interesting are the ones whose risk profile evolves with the product. A people analytics platform like the one we’re building in partnership with Umana Analytics has a cycle in which every new feature potentially touches sensitive data, and every change to the predictive models redefines the contours of the processing. A DPIA-as-form ages fast here: you write it, archive it, reread it a year later and discover its central paragraph no longer faithfully describes what the product is doing. A versioned DPIA-as-genre, by contrast, follows the product. Every pull request touching the processing perimeter opens a corresponding discussion on the relevant paragraph, which may stay unchanged or be updated with a diff that explains what changed and why. The healthcare platform for the Abruzzo region we’ve worked on for years, with its data flow towards a regional registry and national reporting systems, is an even clearer case, because every upstream regulatory change forces a re-reading of the processing — and without a versioned DPIA that re-reading risks losing the thread of the original motivations. With a versioned DPIA, you can start from the present and work backwards, decision by decision, to the point at which the processing was defined, reading the text alongside the discussions that accompanied it. A different case again is the online training platform we run for ECM-delivering bodies, where the DPIA must account for a relatively stable processing but a very large user base and an articulated chain of sub-processors. Here the value of a versioned DPIA lies mostly in keeping the accountability chain aligned as providers change, with every provider update becoming a commit on the relevant section — a coherence a form archived once a year cannot achieve.

Authorial philology and the git log

It becomes important to ask what it really means to version a genre. Literary criticism has a consolidated tradition here: what in Italy we call filologia d’autore, or critica delle varianti — authorial philology, the critique of variants — associated in the twentieth century with the names of Contini and Isella, and which in France took the name critique génétique, with figures like Bellemin-Noël and Pierre-Marc de Biasi. It studies how a text has grown over time, which variants were adopted and discarded, what external pressures modified the form, what rewrites were induced by revisers, commissioners, self-censorship. The git log of a versioned DPIA is, plainly, an avant-texte in real time. It shows when a mitigation measure was strengthened, who proposed it, in response to what report, with what alternatives considered and discarded. It produces, as a side effect, a level of traceability no form-DPIA ever had — because the form hides its history in its final version, whereas the genre puts it on display. And it displays it not out of archival narcissism, but because in a mature genre the history of choices is part of the current argument. An auditor who can read a git log can tell, without asking anyone, whether a given measure was implemented in response to real risk analysis or retrofitted to justify a choice already made. The genealogy of a text is a far more effective quality check than any signature at the bottom.

Working inside this framework changes, in ways my experience shows to be progressive, certain operational dimensions. The first concerns the separation between source and rendering. A form-DPIA lives in its final PDF, with all the misalignment problems that brings: you modify the DPIA and then discover the processing record in another document says something different, or that the executive abstract is still at the version of six months ago. A genre-DPIA lives in a structured source — in our case Confluence, with certain key pages marked for the export pipeline — from which renderings for different readers are generated. The same source produces the complete DPIA for the DPO, an executive abstract for the board, a technical sheet of mitigations for the development team, and optionally a synthetic version for data subjects if the controller chooses to publish it. The content is the same; the form adapts. This demands, at the source, a more rigorous writing discipline than the form-DPIA ever required, because every paragraph must be built to survive multiple uses. In return, it drastically reduces what does most damage in compliance: the proliferation of misaligned versions of the same processing across different documents.

The second dimension concerns the link with project ticketing. In every engagement of ours, a Jira epic or story that touches new processing of personal data, or modifies existing processing, opens a formal request to update the corresponding DPIA. Not necessarily a full update; even a no-impact check is enough, provided it’s recorded. The link makes explicit what in the form-DPIA world was implicit, and therefore forgotten: every product choice is a compliance choice, every feature that touches data is a potential change to the documented processing. Linking the ticket to the DPIA paragraph is, in practice, enforcing that product and its act of writing proceed in lock-step. The git log becomes a genetic history of the processing; the Jira timeline becomes the history of its motivations. For a team used to treating compliance as a satellite activity to development, it’s a non-trivial posture change, and it has to be supported. In the early months we had resistance from developers who saw the Jira–Confluence link as additional bureaucracy; six months in, most of them now consider it a help, because it reduces alignment meetings and makes the technical contribution to compliance visible.

The DPO as editor

The most delicate dimension concerns roles. In a form-DPIA model, the DPO is typically the main author or the final reviewer, and the technical team is an information supplier. In a genre-DPIA model this geometry partially inverts. The DPO remains responsible for compliance, but becomes more properly an editor: sets standards, reviews contributions, ensures consistency across sections, demands rewrites. Whoever writes the first draft of many sections is whoever knows the matter — the product owner, the architect, the developer who designed the data model, the DBA who set the retention policy. The final document is still signed by the DPO and the controller, but the weave of the text is woven by many hands. It’s a thing anyone who has worked in editorial recognises immediately, and that anyone who has only worked in compliance finds disorienting. And yet, after six months of experimenting, it seems to me the healthiest configuration.

I know I’m introducing a tension. A DPO who becomes an editor risks losing in formal authority what they gain in product quality. In the Italian tradition, where the DPO role is often legal and often external to the organisation, proposing a DPO-as-editor can sound like a weakening. I think, instead, it’s a strengthening — for a subtle but important reason. The authority of an editor is not the authority of someone who produces the text alone; it’s the authority of someone who decides what passes and what doesn’t. A DPO who writes everything alone can produce a formally unassailable DPIA that is distant from the operational reality of the processing. A DPO who edits what the team writes remains in the final position of saying no, but does so on material that has a grip on the facts. The result, in my experience, is harder to attack and easier to defend in an inspection.

Legibility is not simplicity

Here we come to the second serious objection I want to address, raised in several internal discussions in recent months. One could say: this recognition of the DPIA as a genre isn’t progress, it’s needless sophistication, a baroquefication of compliance that adds burden without adding value. Europe, goes the argument, already suffers from regulatory inflation; turning the DPIA into a literary product — however technical-literary — means worsening a problem without solving it. I understand the objection, but I think it’s wrong for a specific reason. Genres don’t complicate texts; they make them legible. The alternative to a stabilised genre is not a simpler text, it’s a text that’s harder to read, because the grid letting the reader orient themselves is missing. When the same document reaches a supervisory authority’s desk in ten different forms, written by ten authors each having decided their own structure, reading becomes extremely slow and carries a high margin of error. When the genre is stabilised, the authority can read a hundred DPIAs with the effort an experienced critic reads a hundred novels — by rapidly recognising where to look for what, and noticing just as rapidly the significant deviations.

Legibility, in this sense, is not synonymous with simplicity. A sonnet is harder than a social-media post, but it’s immensely more legible to anyone who knows the genre, because they know where to look for the argumentative turn, the central concept, the closing. In the same way, a well-written DPIA in the new format will be more demanding in detail but faster to read for an auditor who knows the template. And above all, it will be comparable with other DPIAs written in the same form. Comparability is the invisible benefit of stabilised genres, and it will be — I believe — the most important gain in the years ahead for data protection authorities. Until now, every inspection started from reading a document as if it were the first of its kind, reconstructing its form along with its contents. Once the new template is the standard, comparison across a hundred DPIAs from a hundred different controllers will become a feasible operation, because the form will be shared and the differences will be informative.

There is a corollary of this comparability specific to those working with public-sector clients, and I want to develop it because it’s the part of our portfolio changing fastest. In procurement procedures and technical specifications, the DPIA (or equivalent impact documentation) has often been requested as a generic attachment, with little specification on the «how». The administration verified the document existed, leaving substantive review to an often belated stage during contract execution. With a stabilised genre, contracting authorities will be able to do something different — and, from the competitor’s point of view, far more demanding: to assess the document’s quality as a selection criterion. A DPIA written inside the EDPB template can be scored consistently, compared to competitors’, used as an indicator of the bidder’s compliance maturity. For a supplier that has invested in writing as a practice, this will be a clear advantage, because it turns a ritual attachment into a differentiation tool. For a supplier that has always treated the DPIA as an administrative burden delegated at the last minute, it will be a growing risk, because the distance between a well-written document and a botched one will become obvious to anyone reading the template. In our specific sectors — regional healthcare, chambers of commerce, municipalities — I believe we’ll see precisely this kind of selection appearing in award criteria over the next two years: a signal that the genre has entered public-sector contracting no longer as a box to tick but as an object of genuine reading.

The LLM suspicion

There is a third objection that must be faced, even if it requires a digression, and which has been put to me by people very close to our technical practice. If the DPIA is becoming a document of argued prose, the argument goes, then it’s exactly the kind of text a large language model can produce well in minutes. Why worry about all this talk of writing, of authorial philology, of editorial roles, when a good prompt and a couple of iterations will give you a formally impeccable DPIA? The question is legitimate, and I’ve asked it of myself, having worked intensively in recent months with AI-native development tools. The short answer is that the objection conflates two different things, and the conflation is dangerous. An LLM can indeed produce text that looks like a DPIA and will, in most cases, pass a superficial formal check. But a DPIA is not just its final text; it is the documentary trace of a decision process. Its sections are not an autonomous rhetorical display; they are the return of real conversations that took place between real people about real processing activities. An LLM can help me render those returns better, give the text rhythm, suggest more effective phrasings — and it does. It cannot substitute for the conversations upstream of the text, because those conversations are exactly what the DPIA has to account for. A DPIA produced by an LLM without those upstream conversations is a simulacrum, and the difference from the genuine becomes visible soon — particularly when the moment comes to defend it before someone asking precise questions. The genre, here, protects those who practise it honestly and exposes those who fake it, because the depth of a well-written DPIA is inseparable from the depth of the reflection that produced it. This, parenthetically, is a point the culture of AI-native development is learning in every domain it reaches: automatic tools are excellent amplifiers of thought, but not substitutes for thought. And it is precisely in mature genres that the difference between the two becomes clearest.

An ecosystem of techno-normative genres

There’s a related point worth flagging, though it deserves an essay of its own. The genre-DPIA, precisely because it lives in the same ecosystem as the product, lends itself to integrations the form-DPIA could not have. I’m thinking in particular of the link with the SBOM, the software bill of materials, which is becoming an increasingly formalised requirement under the Cyber Resilience Act. The two documentations, SBOM and DPIA, have separate histories and different logics, but they speak about the same platform. When both live versioned and queryable, things become possible like: identifying which software components are involved in the sensitive-data processing described in Section X of the DPIA, or flagging when a dependency upgrade introduces a component that changes the documented risk profile. A developer updating a logging library, say, can automatically receive an alert: «this library is referenced in the DPIA for project Y, paragraph 4.2, check whether the new version changes the described behaviour». These are scenarios that, under an integrated product perspective, remain science-fictional; under an integrated compliance perspective they become — if not easy — at least thinkable. And the reason they become thinkable is, once again, that the DPIA is turning into a text governed by known conventions, navigable as a text is navigable, and no longer a grid opaque to the outside world.

The SBOM–DPIA link, incidentally, is the point at which I realise the argument I’m making has implications wider than the DPIA itself. If the DPIA is turning into a genre, it’s reasonable to ask whether other artefacts of European compliance are undergoing the same transformation, and in what direction. It seems to me evident, for example, that the AI Act technical file is also on trajectory towards a genre identity, with its canonical sections, its argumentative rhythm, its claim to legibility by a market surveillance authority. The same holds, at a different level, for vulnerability documentation and disclosure policies the Cyber Resilience Act is stabilising over the course of this year, with reporting obligations kicking in in September 2026 and full substantive obligations from December 2027. We are witnessing, in Europe, a decade-long operation of techno-normative genre generation, whose consequences for software work remain largely unexplored. Ten years ago, software compliance was a constellation of forms. Ten years from now, in all likelihood, it will be a library of genres, each with its own canons, its reference specimens, its consolidated criticism, its school of authors.

This perspective, abstract as it may sound, has a concrete commercial implication that I think is still discussed too little. A firm that has learned to write inside mature normative genres has a substantial competitive advantage over one that has to learn from scratch every time. And learning to write inside a genre isn’t something done in a one-week course: it requires practice, correction, exposure to good and bad specimens, peer critique, progressive experience of which phrasing holds and which doesn’t. Europe is building, with uneven timing and coordination, an ecosystem of techno-normative genres that will reward organisations capable of making this writing a stable competence. For those of us who do this work — software for public administration and healthcare — it means the next five years will not be won by those who write more elegant code, but by those who write better compliance documents. By «better» I mean not more detailed but more legible, more argued, more capable of sustaining scrutiny from competent readers. It’s a paradigm shift that cuts across our organisations and redefines which competences are scarce and which are not.

I return, then, to the DPIA, with an observation I hope doesn’t sound too abstract. The fact that a form is turning into a genre is one of those things that, once it has happened, retroactively changes how we read the preceding history. DPIAs written between 2018 and 2025 were already, to some extent, genre — because reading expectations existed, because specimens considered good or bad circulated, because authorities were starting to build an implicit jurisprudence of what a well-done DPIA meant. It was a genre in formation, fluid, with uncertain boundaries. The EDPB template, once the consultation closes and national adoption steps are under way, will fix those boundaries, crystallise the genre, and in doing so make retroactively visible a trajectory that was previously ambiguous. From that moment on, the DPIA will have a before and an after, and the difference between them will not be a matter of detail but of nature. The window in which we’re writing now is exactly the moment this transition is completing: no longer before, not entirely after — it is the threshold.

What to do tomorrow morning

I realise all of this may sound, to a pragmatic engineer, like useless philosophical abstraction. What does it help me tomorrow, in concrete work, to know the DPIA is becoming a genre? I’ve already scattered the practical answer through the preceding paragraphs, but it’s worth recomposing it into a form closer to what a team needs to do when opening the next project. Stop treating the DPIA as a closing document produced downstream of design, and start treating it as an accompanying document born with the project and growing with it. Accept that the people who contribute to the DPIA are no longer only legal and the DPO, but also whoever builds the product — and this requires a small but continuous investment in their ability to write argued text. Introduce, in development processes, the technical and organisational links between project tickets and DPIA paragraphs, so writing stops being a parallel activity and becomes part of current work. Rethink the DPO’s role as editor rather than sole author, with everything that implies for relations with the rest of the team. None of these changes is dramatic on its own. Together they redesign how data compliance is practised, and surface the difference between organisations that have understood the shift and those that will keep producing forms in a world that reads genres.

There is, then, something I want to flag to anyone, like us, operating precisely in this window of genre formation. The public consultation the EDPB has opened isn’t a formal exercise concerning only data protection specialists: it’s the moment when the template is still being shaped, and therefore the moment when an informed voice can leave a mark. A software supplier to Italian public administration sending a reasoned contribution, grounded in concrete experience writing DPIAs for public entities, participates in defining the genre more than they might imagine. This isn’t a symbolic gesture: the consultation is the instrument through which European authorities gather edge cases, operational difficulties, incompatibilities with consolidated practice, and reformulate sections in response. In the next two months, from now to 9 June, there is time to contribute. After that, it will be late in the specific sense that the canon’s forms will have been chosen. It’s worth spending a day on it.

An hour of rewriting

I want to close with an image that came to me a few weeks ago, re-reading for the umpteenth time a paragraph on mitigation measures in the DPIA for a healthcare project. The paragraph was formally correct, covered the required points, cited the right norms. But it was badly written, with that particular opacity that uncared-for technical texts have, where syntax is essentially a parking lot for clauses. I re-read it thinking: if an auditor reads this passage quickly, what do they take home? The answer was: almost nothing — because the text isn’t made to be read quickly; in fact, it isn’t made to be read at all. It’s made to be present. It’s compliance archaeology before it’s even been filed. I spent an hour rewriting it, without adding content, merely ordering the rhythm. By the end the paragraph was 30% shorter and, most importantly, said the same things with a clarity it hadn’t had before. The difference was editorial, not technical. But it was exactly the difference that separates a form from a genre.

That hour of work, I think, is the exact measure of the change I’m trying to describe. In a form-DPIA world, an hour of rewriting on a formally correct paragraph is wasted time: the document is compliant, close the ticket, move on. In a genre-DPIA world, that hour is the only truly productive part of the day, because it’s the only part that improves the text’s quality as text. The transformation we’re describing, in short, also changes the definition of time well spent. It changes what a team is authorised to consider work. And therefore it changes how work is to be planned. A sprint planning that reserves two hours a week to collaborative DPIA writing and review is not the eccentricity of a team that enjoys wasting time on technical literature; it’s a team that has understood which documentary regime it is starting to operate in. A team that keeps treating the DPIA as an artefact to produce in one afternoon at project’s end is, literally, living in a regime that is ceasing to exist.

This small episode connects, in my head, to a thread I’ve been pulling on for months across apparently different things: software that doesn’t age well, the product ceasing to be a stable category, the internet having been enclosed rather than degraded. In all these cases the underlying question is the same, and it concerns writing. When a technical artefact ceases to be self-sufficient and becomes part of an ecosystem of texts that document its existence, the text’s properties matter as much as — and often more than — the artefact’s. Modern software, I argued in Cruft, Not Patina, doesn’t age because it’s never finished enough to age. The DPIA, in a mirror image, can no longer be finished enough to be archived: it lives as long as the processing it documents lives, and each of its versions is a photograph in motion, not a monument. Compliance is becoming, almost without anyone noticing, a practice of continuous writing rather than of final archiving. And like every practice of continuous writing, it rewards those who take it seriously as writing, not those who fake it as form-filling.

It’s a direction that will demand more of whoever writes, but will also give back more, in the long run, in terms of decision quality, defensibility of choices, transmissibility of accumulated knowledge. Translating it into practice, into our own workflows, is the work ahead for the coming months. It’s not urgent in the sense of deadlines; it’s urgent in the sense that the longer one delays, the more writing debt accumulates. And writing debt, in a genre still stabilising, is hard to repay when the moment of judgement arrives. Anyone writing their first DPIAs in the new template now is also, perhaps without fully realising, taking part in the formation of a canon. Over the next two or three years, the aggregate of thousands of European organisations’ concrete practices will decide which features of the genre become normal and which remain marginal. It’s worth being there — for once, not as spectator but as author.

The author

Andrea MargiovanniDigital sovereignty

I help public bodies and private organizations read their own infrastructure dependencies. Digital sovereignty is a lattice, not a flag; and it is measured more on contracts than on speeches.

See the guide →