A security review that always came too late
The client processes card payments for merchants across several European countries. Like most organisations in the payments sector, they have a security review board with real authority: nothing that touches cardholder data goes live without its approval. The board took that responsibility seriously, and the reviews were thorough. The problem was when they happened.
By the time a solution reached the board, it had been designed, budgeted and largely built. The review worked from whatever documents the project could assemble in the week before the meeting, which usually meant slides drawn for the occasion. When the board found a problem — and with card data in play, it regularly did — the choices were unattractive: rework something already built, or accept a compensating control that everyone knew was a patch. One tokenisation project went through the cycle twice, and the second rework cost more than the original build.
The security officer wanted the review moved earlier. The difficulty was that earlier in the lifecycle there was nothing to review — no document existed yet that showed where trust boundaries sat, which flows carried sensitive data, and which controls were proposed. Our engagement, which began as broader Sparx EA consulting, took on a specific goal: give the review board something reviewable before implementation starts, and keep it in the architecture repository rather than in slide decks.
What we found when we looked
The organisation was not starting from nothing. Sparx EA was in place and held a reasonable application portfolio. Infrastructure kept detailed network diagrams. There was a PCI DSS scope document, updated annually for the assessor. And every project produced its own security diagrams when asked.
What was missing was any connection between these. The network diagrams showed segments and firewalls but said nothing about what data moved across them. The PCI scope document named systems, but its names did not always match the names in the repository or the CMDB. The project diagrams were the real concern: each one invented its own notation, its own zone names and its own level of detail, so the review board spent the first half of every session decoding the picture rather than assessing the design. Two projects had drawn the same payment gateway in the same quarter, in different shapes, with different neighbours.
There was also no shared definition of a trust boundary. Some people meant network segments, some meant organisational responsibility, some meant the PCI cardholder data environment. In workshops we heard the word "zone" used in three different meanings within an hour. Whatever we modelled had to settle that vocabulary first.
How we set up the work
We ran the work as a series of two-hour workshops over about three months, anchored on one concrete change: a new merchant onboarding portal that altered how card data entered the organisation. Modelling an abstract security architecture for its own sake tends to drift; modelling it for a change that the review board would soon see kept everyone honest.
The standing group was small — the security officer, the lead architect, an infrastructure engineer and the product owner for the change — with specialists invited when a specific flow needed them. Each session took one data flow at a time, from wherever the data entered to wherever it settled. Between sessions we consolidated the results in the Sparx EA repository and brought the updated views back for correction.
Two ground rules did most of the work. First, no discussion of controls until the flow itself was agreed — otherwise every session became a firewall debate before anyone knew what was flowing. Second, everything drawn in a workshop had to exist exactly once in the repository. If the payment gateway appeared on four diagrams, it was the same element four times, with one name, one owner and one set of properties. That rule is what makes a repository different from a stack of drawings, and we held to it even when it slowed a session down.
Modelling trust boundaries in Sparx EA
We modelled the zones with ArchiMate grouping elements, stereotyped as trust zones through a small extension so that they carried a defined set of tagged values: a classification (cardholder data environment, internal, partner-facing or public), a named owner, and a reference to the network segments that implement the zone. The stereotype and tagged values were packaged so every new diagram offered them consistently — the same approach we describe in our article on custom toolboxes with MDG Technology.
The zones are deliberately logical, not network drawings. A zone answers the question "what do we trust here, and who answers for it", and it maps to network segments through the tagged reference rather than by redrawing VLANs in ArchiMate. Keeping that separation was harder than it sounds. The infrastructure engineer could draw the network from memory and kept wanting to add detail; the discipline of stopping at the boundary — this zone corresponds to these segments, and the segment detail lives in the network documentation — kept the views readable for the board.
In the repository, the security content got its own home: a Security Views package holding the zone definitions and the boundary-crossing diagrams, sitting beside the application portfolio rather than inside any project's package. Project work references the zones; it does not copy them. We baselined the package — together with the application packages its views reference — at each review milestone, so the board can always answer "what did the boundary picture look like when we approved this" by comparing against the baseline — a small habit that later proved its worth during an assessor visit, when the question was asked almost verbatim.
Agreeing the zones themselves took two full sessions. We started with nine candidate zones and merged down to six once it became clear that some distinctions changed nothing about data handling or ownership. A zone that never changes a decision is decoration. The six that survived — public edge, merchant-facing services, the cardholder data environment, internal processing, partner connections and the corporate office environment — each had a different owner or a different handling rule, which is the test that mattered.
Following the sensitive data
With zones agreed, the workshops walked the data. Each movement of data between applications became a flow relationship in the repository, and each flow carried tagged values for what it moved: the data classification, recorded at the highest sensitivity the flow carries — full card number over token over personal data over none, the protocol, and whether it was encrypted in transit. The rule we enforced was narrow and absolute: any flow that crosses a zone edge must have its classification filled in. Flows inside a zone could wait; crossings could not.
Figure 1 shows the shape this produced for the core of the estate. The merchant portal sits in the merchant-facing zone and hands card data to the payment gateway at the edge of the cardholder data environment; inside that environment the tokenisation service exchanges card numbers for tokens against the card vault, and everything that leaves the environment — towards fraud screening, settlement and the wider internal zone — carries tokens or aggregates, never the card number itself. Drawing it this way made one earlier design decision visible and defensible: the vault and the tokenisation service are the only elements that ever store the full number; everything upstream — portal and gateway included — handles it in transit only, which keeps those systems inside the environment’s scope but confines the stored-data footprint to two places.
The walk-through also surfaced flows that nobody had drawn before. A reporting extract pulled settlement data through a path that skirted the environment's edge, and a support tool read from a database replica that placed it, unnoticed, inside the cardholder data environment. Neither was a scandal; both changed the PCI conversation. The support tool was moved to read from a tokenised replica instead — and once its connectivity was re-homed and the segmentation verified, the assessor agreed it sat outside the environment. One system fewer is the kind of outcome that pays for the modelling effort on its own.
Granularity was a running judgement call. We modelled flows between applications, not between processes or servers; where one application spoke to another over several endpoints, that was still one flow unless the endpoints carried data of different classifications. The test we applied each time was whether splitting a flow would change a classification, an owner or a control. If not, the split added maintenance without adding meaning. This kept the register at around eighty flows for the core estate — large enough to be complete, small enough that the workshop group could actually review it end to end in a session.
Where the controls sit
Only after the flows were stable did the workshops turn to controls, and the model gave that discussion a precise grammar. Each proposed control became a requirement element stereotyped as a security control, linked to the flow or component it protects, with a realisation relationship from the mechanism that implements it. Mutual TLS on the partner connections is realised by the API gateway; encryption at rest in the vault is realised by the hardware security module behind it; the prohibition on card numbers in log output is realised by the logging library and checked by a scanning job.
The value of this structure is that a control is never free-floating. In the old slide decks, a list of controls sat on the final slide, and the board had to take on faith that each one attached to something real. In the model, a control with no realisation relationship visibly has no mechanism named for it, and a sensitive crossing with no control pointing at it is visibly uncovered in the design. Both conditions can be queried, which turned out to matter more than the diagrams themselves.
We kept the control catalogue shallow on purpose. The security team maintains its full control framework elsewhere, mapped to the standards they answer to; the model holds only the controls that attach to an architectural element or flow, with a reference back to the framework entry. Duplicating the whole framework into Sparx EA would have created a second copy to keep current, and a second copy is one more thing to fall behind.
Checking the model before the review
Rules that live in workshop minutes get forgotten, so we wrote the rules down as model searches. Three did most of the work: flows that cross a zone edge without a data classification; flows classified as carrying card numbers or personal data without a linked control; and elements inside the cardholder data environment without a named owner. Each search is ordinary SQL against the repository — zone membership is queryable because every element carries a zone tagged value, written when it joins a zone view — and the search definitions ship with the extension, so every client has them.
Sparx EA’s built-in model validation enforces notation conformance, and custom rules can be added through the API, but checks over tagged values and linked controls are simplest to write and maintain as searches, so that is the route we chose. We scheduled them through the automation API to run weekly and post the exception list to the team channel, an approach we have described more generally in our guide to the Sparx EA automation API. The exception list was long in the first weeks and boring within two months, which is exactly what a check should become.
A model earns its place in a security process only if it can answer questions faster than a meeting can. "Show me every unprotected crossing into the cardholder environment" became a thirty-second query. That is the capability the review board ended up relying on.
The review itself
The merchant onboarding change went to the review board before implementation, on the strength of the model. The board received a generated document rather than project slides: zone views, the register of boundary crossings with their classifications, and the control mapping, all produced from a Sparx EA document template so that the document could be regenerated whenever the model moved. Members who wanted to look further were given read access to the views themselves.
The review found two things it wanted changed — a key rotation period on the vault that the proposal had left unspecified, and a partner flow whose fallback path bypassed the API gateway under failure conditions. Both findings became changes to the model first: the control gained an explicit rotation requirement, the fallback path was redesigned and redrawn. Implementation then proceeded against the corrected design. Finding the fallback problem on a diagram cost a week; finding it after build would have cost a release.
Just as importantly, the review was short. The board was not decoding a new notation; it was reading views in a shape it had already agreed to, against rules it had helped define. The chair's comment afterwards was that it was the first review in which the discussion started at the level of the design rather than the level of the drawing.
Making it repeatable
One good review is a pilot; the engagement only counts as finished when the second and third changes go through the same gate without us in the room. So the last stretch of the work was deliberately unglamorous: turning what the workshops had done by hand into things the organisation could repeat.
The document template was the first piece. The review pack — zone views, crossing register, control mapping — is generated from the repository through a Sparx EA document template with fragments for the register tables, so producing a pack for a new change is a matter of scoping the template to that change's diagrams and running it. The first pack took us two days of template work; every pack since has taken the project architect under an hour. We have written elsewhere about what EA's document generation can and cannot do; here it did exactly what it is good at, which is producing the same document shape from different model content.
The second piece was a worked example. Rather than writing a modelling guideline document nobody would read, we kept the merchant onboarding views as the reference: a new project copies the pattern from a real, approved change rather than from an abstract instruction. The guideline that does exist fits on two pages and mostly says which stereotypes and tagged values to use and which searches will be run against the result.
The third piece was people. Two of the client's architects ran the final workshops themselves with us observing, and the security officer's team took ownership of the zone definitions. The handover test we set was simple: a change we had never seen, taken from first flow-walk to review pack, without a question to us. It passed on the second attempt, which is typical.
What changed
The immediate change was sequencing: security review became something that happens to designs rather than to systems. In the year after the first review, every change touching the cardholder data environment came to the board as model views, and rework driven by late findings — the cost that had motivated the whole engagement — fell to nearly nothing for those changes.
The quieter change was vocabulary. Zones stopped being a word with three meanings. When someone says "that crossing needs a control" in a design discussion, everyone now pictures the same edge on the same view. The annual PCI scoping exercise also got easier: the cardholder data environment is a query over the model rather than a fresh archaeology project, and the assessor's questions about data paths could be answered by walking flows on screen rather than by convening the people who remembered.
None of this made the organisation secure by itself, and it is worth being plain about that. The model records intended controls. Whether the vault actually rotates its keys is a matter for security testing and operations, not for the repository. What the model changed is when problems are found and how precisely they can be discussed — which, for this organisation, was where the money was leaking.
What we would do differently
We would start with fewer zones. The early sessions spent real energy on distinctions that were later merged away, and the group would have converged faster starting from four zones and splitting where a difference in ownership or handling forced it, rather than starting from nine and merging.
We would also set expectations about enforcement earlier. Sparx EA does not stop a modeller from drawing a crossing without a classification; the MDG extension offers the right tagged values, but filling them stays voluntary at edit time, and the weekly search catches omissions only after the fact. The named limitation here is that the configuration we delivered has no equivalent of a compiler error — a custom add-in can veto edits in EA, but we judged that heavier to build and maintain than the weekly search — so the gate is procedural, not technical. Teams that expect the tool to enforce the rules are disappointed; teams that treat the exception list as part of their weekly rhythm do fine, but that rhythm has to be built deliberately, and we built it later than we should have.
Finally, the mapping from zones to actual network segments needed a firmer owner. The tagged references to segments drifted twice when infrastructure renumbered things, and were caught by accident both times. A quarterly reconciliation against the network source of truth — scripted, like the other checks — went in near the end of the engagement and should have gone in at the start.
Where they are now
Eighteen months on, the six zones are unchanged, which suggests they were cut at the right grain. The flow register has grown as new partner connections were added, each one classified at design time because the review board will not schedule a session without it. The weekly checks still run, and their exception list is still short. The security officer now co-owns the repository's security views alongside the architecture team — an arrangement that was not part of the original plan but has proved to be the thing that keeps the content current.
The pattern has also started to travel. The same zone-and-crossing structure is being extended to cover personal data flows for the privacy team, using the same stereotypes with a different classification set — a reuse we designed for but did not promise, and the clearest sign so far that the approach has become the organisation's own rather than something a consultancy left behind.
If your organisation is facing a similar situation — security reviews that arrive after the decisions they are meant to influence, and no shared picture of boundaries and flows to review — 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.