I've sat in enough security review meetings across enough multinational banks and fintechs to know the pattern before the meeting starts. Someone built something. Someone else has to decide if it's safe enough to ship. And somewhere in between, a process is supposed to make that decision rational instead of a coin toss dressed up in jargon.
Most places don't have that process. They have a checklist that nobody reads properly, a gatekeeper with no actual authority, and a lot of meetings that produce nodding but no decisions. I built the flow I'm about to walk you through after watching that failure mode repeat itself, bank after bank, fintech after fintech, for the better part of two decades.
This isn't theory. It's the thing that actually happens when an application team wants to ship something and the organisation needs to know whether that's a sensible idea. I've drawn it on whiteboards more times than I can count. I've sat through versions of it that didn't work, watched why they didn't work, and kept the parts that survived contact with reality.
It starts with a request
Someone submits a request to review an existing or new application. Simple enough. Then comes the first real decision point: is this thing cyber significant? Does it touch information that's directly relevant to the business mission, or is it the digital equivalent of a noticeboard?
That answer changes the whole shape of what happens next.
- If yes, the application goes to the Enterprise Architecture Board first. Someone checks whether the proposed architecture actually fits the standards the organisation has agreed on — performance, cost, risk, quality, support, data protection.
- If no, it skips that board entirely and goes straight to documentation.
I used to think this was a shortcut for less important work. It's not. It's a recognition that EAB review is expensive in time and attention, and you don't spend that budget on things that don't matter to the business. The significance question isn't a formality. It's triage.
I've watched organisations skip this step entirely and treat every application the same way — full ceremony, every time, regardless of whether it's a payment rail or an internal lunch-ordering tool. That doesn't make anyone safer. It just means the security team burns out reviewing noticeboards while something that actually matters queues behind them. Triage isn't a shortcut. It's the only way the process survives contact with volume.
The questionnaire nobody enjoys filling out
Whichever path you took, you end up here: the Information Security Questionnaire. Architecture diagrams with protocols and networks labelled properly. Data flow diagrams. Sequence diagrams. SAST and DAST results. SOC 2 Type 2 reports. Proof that IAM onboarding actually happened and isn't aspirational. SIEM configuration. An RBAC matrix that reflects reality rather than the org chart from two reorgs ago. Evidence of encryption in transit and at rest.
It's tedious. Application teams hate it. I understand why. But every item on that list exists because I've personally watched a team say they had something — least privilege, monitoring, encryption — and then watched that claim evaporate the moment anyone actually looked.
Here's a version of that I've seen more than once: a team tells you, with total confidence, that role-based access control is in place. You ask for the matrix. There isn't one. What exists is a shared understanding among three engineers about who's allowed to touch what, none of it written down, all of it dependent on those three engineers staying employed and remembering correctly. That's not access control. That's tribal knowledge wearing a badge.
You can't review what you can't see. The questionnaire is how you force the seeing to happen before something goes wrong, not after. It's also, frankly, a forcing function for the application team to find out what they don't actually have, before a regulator or an incident finds out for them.
The architect's actual job
Once the documentation lands, the Security Solutions Architect reviews everything against the Security Control Framework. Threats and risks get documented properly, scored against a threat/risk matrix rather than vibes. This goes to a Security Peer Review Forum — other architects, other disciplines, checking for blind spots the original reviewer didn't know they had.
I've been the architect sitting alone with a stack of documentation, convinced I'd found everything worth finding, only to have a peer in that forum ask one question that unravelled the whole assessment. Not because I was careless. Because everyone has blind spots, and the people most confident about their own thoroughness usually have the biggest ones. The peer forum isn't bureaucracy for its own sake. It's the only mechanism in this entire process that catches the architect's own mistakes before they become someone else's incident.
If there's an Enterprise Architecture Board decision earlier in the chain and it comes back negative, the assessment closes there. Full stop. No appeal route built into this diagram, no consolation prize. I know that sounds harsh written down. In practice it's the opposite of harsh — it's honest. Pretending a rejected architecture might still pass security review later just delays the conversation everyone's avoiding. I'd rather have that conversation in week two than week twenty, after a team's already built half the thing on a foundation nobody approved.
Where the actual argument happens
If deficiencies turn up, the Risk Management Forum reviews the threat and risk of each one. Then the real question: does the application team agree to fix these before going live?
Say yes, and it goes to the Risk Manager to rate and accept. If the Risk Manager doesn't accept that rating, it loops back to be reviewed again — which is its own small lesson. Agreement between teams doesn't automatically mean the risk assessment was correct. Someone still has to sign off on the rating, not just the intent to fix. I've seen architects and application teams shake hands on a severity rating that was, on reflection, far too generous to the application. The loop exists because good intentions and accurate risk scoring aren't the same thing, and conflating them is how "low risk, fixing soon" quietly becomes "critical, ignored for eighteen months."
Say no — the team won't commit to fixing it before go-live — and the risk gets formally logged in the enterprise risk register instead.
Here's the part that surprised me when I mapped this out properly: both paths end up in the same place. Whether the team agrees to fix the issue or refuses outright, someone still has to be assigned to create a Corrective Action Report with a remediation timeline. Disagreement doesn't make the risk disappear into the register and stay there unattended. It just changes who's accountable for chasing it down.
I think that's the single most important design choice in the whole diagram, and it's the one nobody notices on first read. I've worked at places without this convergence point, where a refusal to fix something just meant the finding sat in a spreadsheet, unowned, until an audit found it eighteen months later and everyone acted surprised. Convergence kills that outcome. There's no branch in this process where a known risk simply has no one attached to it.
Closing it out
Eventually everything routes back up to the architect: an assessment summary, a residual risk statement, a final peer review with the architecture team lead. Then one last gate — is PHI or PII landing in the public cloud? If yes, CISO approval is mandatory before anything closes. If no, the assessment closes without that extra layer.
That gate isn't decoration. In financial services, the moment regulated personal data moves into a public cloud environment, the conversation stops being purely technical and starts being a regulatory and reputational one. The CISO needs to see that decision before it's final, not read about it afterwards in an incident report. I've watched what happens when that visibility doesn't exist, and it's never a quiet afternoon for anyone involved.
That's the whole thing. Not elegant. Not particularly fast. But every loop, every "No" branch, every forum exists because I watched the alternative — security review as a rubber stamp, or security review as an obstacle course nobody respects — play out badly, more than once, in institutions that genuinely couldn't afford for it to play out badly.
Whether this version is right depends less on the boxes and arrows and more on whether the people running it actually believe security and application teams are supposed to be on the same side. The process can't manufacture that belief. It can only make the consequences of not having it slightly harder to hide. I've watched it work. I've watched versions of it fail when that underlying trust wasn't there to begin with. The diagram is the easy part. Getting people to actually use it the way it's meant to be used — that's the job that never really finishes.