The audit finding that started it
The client was an insurer of the mid-sized, long-established kind: a few thousand staff, a core platform dating back decades, and a compliance function that took its work seriously. The engagement began, as these engagements often do, with an audit finding. Asked to demonstrate which systems gave effect to a particular set of data-handling obligations, the organisation had needed six weeks, four departments and a great deal of goodwill to assemble an answer — and the auditors noted, correctly, that the answer was assembled rather than maintained. The finding did not say the insurer was non-compliant. It said the insurer could not efficiently show that it was, which in a regulated industry is a finding with teeth.
The compliance function owned a register of obligations drawn from regulation and internal policy — several hundred entries, each with a reference, a summary and a nominated owner. The IT function owned a Sparx EA repository describing the application estate, kept in reasonable shape for portfolio purposes. What did not exist was any maintained connection between the two. The mapping that answered "which systems does this obligation land on" lived in a spreadsheet built for the previous audit, already a year and a half old, maintained by nobody.
We were engaged to make the connection durable: obligations traced to requirements, requirements to controls, controls to the systems and owners responsible — inside the repository the architects already maintained, so that the trace would age with the architecture rather than apart from it.
Two registers that had never met
The first two weeks were spent understanding both sides of the gap. The obligation register was better than we usually find: obligations were individually identified, stably numbered and reviewed on a cycle. The weakness was granularity. Some entries were precise enough to act on, while others — "customer data must be adequately protected" — were policy headings rather than obligations, and no system-level trace would ever hang off them convincingly.
On the architecture side, the repository held around four hundred applications with ownership and lifecycle information, which gave us something solid to trace to. But it had been built to answer portfolio questions, and compliance questions are shaped differently. The repository could say what an application was and who owned it; it could not say what the application was obliged to do, because obligations had never been part of its vocabulary.
The spreadsheet that had bridged the two for the last audit taught us the most. It had decayed in exactly the predictable ways: applications renamed or retired since, obligations revised since, and — most instructively — mappings that were assertions of hope rather than statements anyone owned. Its real lesson was that a mapping without a maintenance mechanism is an audit artefact with a shelf life of one audit.
A small metamodel for obligations
We extended the repository's vocabulary with a deliberately small set of concepts, expressed as stereotyped ArchiMate motivation elements. Regulations and policies were modelled as drivers; individual obligations as stereotyped requirements carrying the register's stable identifier in a tagged value; the insurer's responses to obligations as controls — again stereotyped requirements — with realisation relationships from the application services and components that implemented them; and business roles carried accountability through stereotyped associations — strict ArchiMate has no assignment into a requirement, and we preferred a labelled association to a rule bent quietly. Every obligation element held tagged values for its register reference, its review date, its owning function and its criticality, so that the model could answer the questions audits actually ask without anyone opening a second tool.
Two design rules did most of the work. First, obligations were never linked directly to applications; the chain always ran through a control. The direct link feels efficient and answers nothing — an application "linked to" an obligation tells an auditor only that somebody once drew a line. A control in between states what is actually done, and gives the realisation relationship something concrete to mean. Second, the heading-level entries in the register were modelled as drivers rather than obligations, keeping them visible as context without pretending they could be traced. The compliance team initially resisted splitting their register conceptually; the first linking workshop, where the vague entries proved unlinkable, converted them more effectively than we had.
Organising the repository for audit
Where things live in a repository sounds like housekeeping until an auditor is watching you navigate. We reorganised the compliance-related content into a structure that could be explained in one sentence: a package per regulation family holding its drivers and obligations, a controls package per business domain, and the existing application estate untouched where it already stood. Cross-package relationships carried the meaning, which is what relationships are for; the packages carried ownership, which is what packages are for.
Ownership was enforced rather than hoped for. Sparx EA's package-level security locked the obligation packages so that only the import script's account and two named compliance-trained modellers could write to them — not because colleagues were untrusted, but because an evidence structure whose entries can be casually edited is an evidence structure an auditor can casually discount. The controls packages were writable by the domain architects, whose changes were the point; and we switched on Sparx EA's Auditing for the repository so that changes to the compliance structure were recorded as a history — element authorship and modified dates alone only ever tell you who touched something last, which is not an answer an auditor accepts twice.
We also built a small set of saved model searches as the front door for people who would never browse packages: obligations without controls, controls without realising components, elements whose review date had passed, obligations flagged by the reconciliation as withdrawn. Each search answered one question a compliance officer actually asks, each was reachable from the repository's start page, and together they meant the structure could be interrogated by its owners without anyone learning the model tree by heart. In our experience this is what determines whether a non-modelling function adopts a repository: not training courses, but half a dozen searches with their names written in the user's own vocabulary.
Importing the register without creating a second truth
The obligation register lived in the compliance team's tool, and the last thing the engagement needed was a hand-maintained copy inside the repository — that would simply have rebuilt the doomed spreadsheet inside the repository. We wrote an import script against the Sparx EA automation interface that read the register's export and reconciled it into the model: matching on the stable identifier, creating elements for new obligations, updating summaries and review dates on existing ones, and flagging — never deleting — obligations that had disappeared from the register, since an obligation's withdrawal is itself something a trace should remember.
The script ran on a schedule, and the reconciliation rules were the part we drafted most carefully, drawing on the same principles we apply to model migration work: one system of record per fact, stable identifiers as the join, and every automated change logged where a human reviews it. The compliance tool remained the sole author of what obligations said; the repository became the sole author of how the organisation answered them. Neither side could quietly drift from the other, because the drift itself surfaced in the weekly reconciliation report.
The linking workshops
With the skeleton in place, the substance came from workshops — a dozen of them over about two months, organised by business domain, each pairing the compliance owner of a group of obligations with the architects and system owners of the domain it touched. The format was deliberately repetitive. Take the next obligation; agree what the organisation actually does about it; name that as a control; link the control to the services and components that implement it; assign the accountable role; move on.
The rhythm mattered more than the tooling, but the tooling kept the rhythm honest. Modelling live in Sparx EA meant every agreement became an element and every element carried its tags before the discussion moved on. The Relationship Matrix — obligations down one axis, controls across the other — was on the screen at the end of every session, showing what the session had actually produced and what remained empty. The matrix shows direct relationships only, so the full obligation-to-component picture came from a saved model search that walked the chain through the controls; the two views answered different questions and we kept both. Workshop participants stopped debating whether coverage existed and started debating whether the named control genuinely satisfied the obligation, which is a far better argument to be having, and one no validation script can have for you.
The workshops also produced their share of discoveries. Several obligations turned out to be satisfied by the same three controls — the estate's workhorse security services — which concentrated risk nobody had seen concentrated. One obligation was covered by a control implemented in a system scheduled for decommissioning within the year, with no successor named in the decommissioning plan. Both findings went to the risk committee with diagrams attached.
The rhythm that keeps it alive
The spreadsheet this work replaced had not failed for technical reasons; it had failed because nothing in anyone's calendar required it to be true. So the operating rhythm was designed as deliberately as the metamodel, and more of the engagement's final fortnight went into it than into any artefact. The weekly reconciliation report acquired a single named reader — a senior compliance officer — whose Monday routine included confirming that new obligations had landed in a triage list and that flagged withdrawals had been reviewed. We attached the routine to a meeting that already existed rather than creating a new one, on the well-tested principle that new mechanisms survive best when they cost no new calendar entries. Triage itself was a ten-minute standing agenda item in the compliance team's existing weekly meeting: each new obligation was assigned to a domain, which determined which architect would see it and in which domain's next linking session it would be worked — with anything that could not wait a quarter taken up directly with the domain architect rather than left to the cycle.
The linking sessions continued after our engagement at a much lower intensity — quarterly per domain rather than weekly — timed to precede the compliance function's own register review cycle, so that architecture confirmations fed the review rather than trailing it. Each session had a fixed opening move: run the gap searches, look at what had appeared since last time, and only then discuss anything new. Reconfirmation was explicit — the last-confirmed date on a link was updated only when a human had actually looked at it — because a date that updates itself is a date that certifies nothing.
None of this is sophisticated, and all of it is the difference between a mechanism and a monument. When we checked in with the client a year later, the rhythm was intact, two people had changed roles without the routine dropping, and the register-to-repository join had survived a reorganisation of the compliance team — which is the test the original spreadsheet had failed within eighteen months of its creation.
The gaps, counted honestly
When the linking pass was complete, a handful of obligations had no control at all, and a slightly larger number had controls that no application service realised. Some of those were genuinely manual — procedural controls carried out by people, which we marked as such and linked to the responsible role. The remainder were paper controls in the bad sense: documented responses with no implementation of any kind behind them. The temptation in an engagement like this is to tidy the picture before showing it to anyone. We did the opposite, on the principle that the gaps were the most valuable output of the exercise: each empty row in the matrix became an action with an owner and a date, tracked by the compliance function in its own tool, and the model search that found the gaps was saved so the count could be reproduced on demand by anyone with repository access.
A traceability model that arrives showing full coverage on day one is hard to distinguish from one drawn to show it. The version that earns trust arrives with its gaps visible, owned and dated — because that is what tells an auditor the mechanism is real.
It is worth recording that the gap count went up before it went down. Two workshops in, architects who had seen how the trace worked began volunteering obligations the register itself had missed — undertakings made in customer terms and conditions that had never been registered as obligations at all. The register grew by a modest number of entries as a result, which the compliance team rightly counted as the mechanism working rather than failing.
Evidence packs generated from the model
The audit-facing output was a set of documents generated from the repository with Sparx EA's document templates. For each obligation: its register reference and summary — the authoritative text stays in the compliance tool and is cited, not copied — the controls responding to it, the application services and components realising each control, the accountable roles, the relevant diagram, and the dates on which each link was last confirmed. The template work took about a week, most of it spent making the generated document read like something written for auditors rather than exported at them — ordering, headings and plain-language link descriptions, following the practices we describe in our work on document generation from Sparx EA.
Alongside the per-obligation packs, two standing views were published for internal use: the full obligation-to-system matrix for the compliance function, and a per-application view for system owners showing every obligation their system helped satisfy — which proved unexpectedly popular with the owners themselves, several of whom had never seen their compliance surface in one place. Publication ran on a schedule, so the packs were always regenerated from current content rather than saved from a good moment.
Freezing the trace at audit time
One capability turned out to matter more to the auditors than we had anticipated: Sparx EA's baselines. At each audit submission, and at each quarter-end, we baselined the compliance packages — a snapshot of every obligation, control, link and tag as it stood at that moment, named to a simple convention that included the date and the occasion — and, at audit submissions, the application packages the controls pointed into, since a trace frozen on one end only is half a snapshot. The document templates were versioned alongside in the same repository. Baselines are cheap to create, and the discipline of creating them on a calendar rather than on inspiration is the entire trick.
What the baselines bought was the ability to answer as-of questions, which are the questions audits are actually made of. An auditor rarely asks only "which systems satisfy this obligation"; sooner or later they ask "and was that also true in March, when the incident happened". Without baselines, the honest answer is a reconstruction; with them, it is a comparison view against the snapshots either side of the date in question, with the audit log covering the interval between — which links existed, which have been added since, and which control was still realised by the now-retired system. The first time we demonstrated that comparison live, the auditors' follow-up questions became noticeably more specific — which we took as the sound of a mechanism being trusted with harder work.
The baselines also protected the client from its own progress. Twice during the year, restructuring in the controls packages would have made an old evidence pack irreproducible from current content; because the packs cited their baseline, regenerating any historical pack remained possible. Storage cost was never worth discussing — the snapshots are XML inside the repository database, and a year of them amounted to less space than a single scanned audit binder.
The next audit
The measure the client cared about arrived with the following year's audit cycle. The request that had previously taken six weeks was answered in under a week, most of which was review rather than assembly: the packs were generated, the compliance owner read them, and the auditors received documents whose provenance they could interrogate down to individual model elements and dates. The finding was closed. The auditors' working papers reportedly described the mechanism as stronger than what they typically see at organisations of this size, which we pass on with the caveat that we heard it second-hand and auditors are not in the habit of writing testimonials.
The quieter change was in how architecture change interacted with compliance. Decommissioning proposals now went to the review board with the affected obligations listed automatically — the query is a traversal from application to control to obligation — and one migration plan was revised when the trace showed a control would be orphaned mid-transition. The compliance function, for its part, stopped maintaining mapping spreadsheets entirely. The join between the two registers had become infrastructure, with a script and a schedule, rather than a heroic annual effort.
On cost, since prospective clients always ask: the ongoing burden settled at something like a day a month of architect time across the domains for reconfirmations, plus the compliance officer's Monday routine, plus quarterly sessions that mostly ran short. Set against the assembly effort each audit had been costing — six weeks of elapsed time, with person-weeks scattered across four departments inside it — and the standing anxiety of an open finding, the client judged the arithmetic not close. The larger investment was the initial one — the metamodel, the import script and roughly two months of linking workshops — and the honest way to describe it is that the client bought a durable mechanism for approximately the cost of one more heroic spreadsheet rebuild, done properly this once.
What the model deliberately does not hold
Three boundaries were drawn on purpose, and we were explicit about them in the handover. The repository does not hold obligation text as its master — the compliance tool does, and the model carries identifiers and summaries only, so that legal wording is never versioned in two places. It does not hold evidence documents — certificates, penetration test reports, DPIAs — but references to where they live, because a modelling repository makes a poor document safe and a worse one at scale. And it does not attempt to say whether a control is effective; it says the control exists, what implements it and who answers for it. Effectiveness belongs to testing and assurance, and a model that claimed it would be overreaching in a way auditors are professionally trained to notice.
The named limitation, then, is that Sparx EA gave this insurer a maintained map of accountability, not a compliance verdict. The map is the part that was missing, and the part that made every other compliance activity cheaper — but it is a map, and we have found that saying so plainly is precisely what makes regulated clients trust the rest.
If your organisation faces an audit finding of the "cannot efficiently demonstrate" kind, or maintains its obligation-to-system mapping by annual heroics, this pattern transfers well. Our Sparx EA consulting covers metamodel design, scripted integration and the workshop process described here, and you can reach us through our contact page.
This case study describes a representative engagement pattern. Organisational details are illustrative and do not identify a specific client.