Six actions that put security inside the enterprise architecture

A few terms first

TOGAF is a widely used method for designing how a company's business, data, applications and technology fit together. That design is the enterprise architecture, and the people who produce it are enterprise architects.

TOGAF organises the work as a repeating cycle of phases. Along the way it uses a few things this article refers to:

• Principles: short rules every design must follow, such as "one login system for all customer services".
• Architecture Board: the group that approves or rejects designs.
• Requirements repository: the single list of everything the systems must do.
• Building block: a reusable, pre-approved component or pattern, such as "the company's central login service".
• Roadmap: the ordered plan of what gets built when.
• Architecture contract: the written agreement a project signs, stating what its design must satisfy.

The problem

Security usually arrives after the design is finished. The systems are chosen, the plan is agreed, and only then does someone ask if it is safe. Every fix at that point is a retrofit. It costs more and it usually ships watered down after a fight.

A bigger security review at the end will not fix this. Putting security into the six places where the architecture is decided will, because after that the method carries security on its own.

Action 1: write security into the principles

The principles are the rules every design is checked against. Add a few security rules to them, in the same format as the others, and get them approved by the board. From then on every project is measured against them whether or not you are present.

Keep them few and testable: "least privilege by default", "classify data before storing it", "all customer services use the central login".

Example: a bank adds the central-login rule. Two years later a project proposing its own login is rejected by citing the rule, without any security review.

Action 2: sit on the Architecture Board

This is where decisions are made. A review afterwards can only object, which is why security gets a reputation for slowing things down. Ask for a permanent seat.

Also agree how disputes are settled: when security risk and delivery deadlines clash, the board decides on a written trade-off.

Example: a company adds security as a fixed agenda item. Within a few months the enterprise architects start raising security questions themselves, because they know the slot is coming.

Action 3: put security requirements in the shared list

If your requirements live in a separate security document, nobody will find them. Use the same list, the same template and the same numbering as every other requirement.

Each one should show its chain: the business need, the risk it addresses, the requirement itself, the building block that meets it, and how it was verified.

Example: an insurer's need "sell policies online in Europe" leads to the risk "health data seen by the wrong staff", which becomes requirement SEC-014: "health data accessed by role only, every read logged". It sits next to the functional requirements and the same project team picks it up.

Action 4: register security building blocks

Projects reuse what is in the catalogue and reinvent what isn't. Register the central login service, key management, the logging pipeline and the network separation pattern as approved building blocks, each pointing to the requirement it satisfies. A project that assembles approved blocks inherits their approval, which also shortens reviews.

Example: the insurer registers "central login" and "audit log pipeline". The next three projects handling health data reuse both and skip the design debate.

Action 5: put the security foundations first in the roadmap

Most security debt is created here. The central login service is postponed to "phase 2", and meanwhile every project builds its own.

Argue for the central login service as the first thing delivered, before the applications that need them, with budget and an owner named in the plan.

Example: "central login live" is placed first. The three applications that follow are each scoped without their own login work.

Action 6: write security criteria into the contract

A contract with security criteria turns the final review from opinion into a check. If a project deviates, it files a formal change request and the board decides, instead of the deviation being accepted by default.

Example: the contract says "no direct database access from internet". The team's request for direct access from internet is filed, discussed and refused with a recorded reason.

Order of attack

Start with actions 1 and 2 in the first quarter, because they win you the right to be in the room. Actions 3 and 4 follow as soon as you can write to the shared lists. Actions 5 and 6 wait for the next planning cycle, since the roadmap and the contracts are only rewritten then.

How you know it worked

Other architects start quoting the security rules in reviews, and security requirements show up in the shared list before you have added them. Projects reuse the registered security blocks. The board raises security trade-offs without being asked. And nobody remembers the last time security was a surprise.

Checklist

1. Principles

• [ ] Read the existing principles; note where security is missing.
• [ ] Draft three to six security rules in the same format.
• [ ] Get them approved by the board.

2. Architecture Board

• [ ] Find out who sits on the board and who leads it.
• [ ] Request a seat.
• [ ] Agree how risk-versus-deadline disputes are settled.

3. Requirements

• [ ] Get write access to the shared requirements list.
• [ ] Enter security requirements in the standard template.
• [ ] Link each to a business need and a risk.

4. Building blocks

• [ ] Register login service, key management, logging and secure network patterns, etc.
• [ ] Link each to the requirements it meets.
• [ ] Tell project architects they exist.

5. Roadmap

• [ ] Add security work items next to the functional ones.
• [ ] Push central login services, etc. to the front.
• [ ] Confirm budget, owner and date for each.

6. Contracts

• [ ] Put security criteria in every project contract.
• [ ] Attend the final reviews.
• [ ] Record every deviation as a change request with a decision.

Habits

• [ ] Describe problems as business risk rather than by policy number.
• [ ] Offer options with trade-offs instead of vetoes.
• [ ] Work in their templates and tools rather than a separate security drive.
• [ ] Give credit publicly when a project ships securely thanks to a registered pattern.

Enjoyed this? This is the kind of reasoning I bring to security teams every week.

I help in three ways: training your consultants or engineers to think like security architects over 4 weeks, Risk Expert, a SaaS to run risk assessments and keep a risk register in line with ISO 27001/27005, PCI DSS, GDPR and the CRA (European Cyber Resilience Act), and a retainer where I manage the risk analysis of your new projects myself.

Start with a free audit of your context at securityarchitect.xyz — I'll tell you plainly if I can help or not.