Khürt Williams (@khurtwilliams.indieweb.social.ap.brid.gy)

Security Review Philosophy: Collaboration Over Compliance I’ve spent the better part of two decades watching application security reviews fail in predictable ways. They fail when security becomes a gate instead of a partnership. They fail when documentation becomes performative rather than diagnostic. They fail when the people conducting the reviews lack the authority to influence outcomes but carry all the responsibility for risk. After enough iterations, enough frustrated application teams, and enough security incidents that slipped through elaborate review processes, I built something different. The document I’ve shared here represents a synthesis of those failures and the lessons extracted from them. It’s not revolutionary—there are no novel security controls or cutting-edge threat modelling frameworks embedded in these procedures. What it does attempt is something more fundamental: it tries to create a structure where security review becomes a collaborative exercise in understanding rather than a compliance checkbox. The philosophy underpinning these procedures acknowledges a simple truth that many security organisations struggle to accept: application teams aren’t trying to circumvent security, they’re trying to deliver business value within constraints they may not fully understand. The first design choice—placing the Security Solutions Architect at the centre of coordination—isn’t about centralising power. It’s about creating accountability. When everyone is responsible for security, no one is responsible for security. The SSA role exists to be the single thread that pulls together enterprise architecture concerns, risk management decisions, peer review feedback, and CISO oversight into a coherent assessment. This person isn’t a gatekeeper; they’re a translator and coordinator who ensures that the application team’s technical reality gets accurately represented to the various governance bodies that need to understand it. But here’s the trade-off: this model requires security architects who can operate across multiple domains. They need to understand threat modelling and risk assessment, yes, but they also need to navigate enterprise architecture politics, speak the language of application developers, and know when to escalate to the CISO versus when to work through issues collaboratively. Finding people who can do this well is harder than finding people who can identify OWASP Top 10 vulnerabilities. Training them takes time. The process documentation can’t compensate for lack of skill or judgement. The questionnaire-driven approach in Step 2 addresses a problem I’ve encountered repeatedly: application teams and security teams often talk past each other because they’re operating with different mental models of the system. Asking for architecture diagrams with labelled protocols and networks, data flow diagrams, and sequence diagrams forces both parties to develop a shared understanding of what actually exists. The assurance documentation—SAST, DAST, SOC 2 Type 2 reports—isn’t about ticking boxes. It’s about establishing a baseline of external validation that the security team can build upon rather than starting from zero trust. The RBAC matrix and encryption evidence requirements deserve special attention. These are areas where I’ve seen the most significant gaps between what application teams think they’ve implemented and what actually exists in production. Requiring explicit proof of IAM onboarding and SIEM configuration isn’t bureaucratic overhead—it’s a recognition that without observability and access control, every other security control becomes theoretical. You can’t detect or respond to what you can’t see, and you can’t enforce least privilege without role definitions. The cyber significance assessment in Step 4 is a filtering mechanism born from pragmatism. Not every application deserves the same level of scrutiny. A marketing website that collects email addresses for a newsletter isn’t equivalent to a payment processing system or a platform that handles PHI. The risk-based approach here prevents security teams from becoming bottlenecks whilst ensuring that genuinely significant applications receive appropriate attention. The challenge is defining “cyber significant” in ways that make sense to both security and business stakeholders. I’ve deliberately kept the definition broad—applications that process or store information directly relevant to the organisation’s business mission—because rigid categories inevitably miss edge cases. Involving the Enterprise Architecture Board at Step 5 is perhaps the most controversial design decision. Many security processes treat enterprise architecture as a separate concern, something that happens before or after security review. I’ve found this separation creates blind spots. Architecture decisions about technology stack, deployment model, or data residency have profound security implications. Conversely, security requirements influence architecture in ways that affect performance, cost, and operational complexity. The EAB review ensures these concerns get addressed in an integrated way rather than creating conflicts that application teams have to resolve through workarounds. The threat assessment in Step 7 is where theory meets reality. Questionnaires and documentation provide structure, but understanding the actual threat landscape for a specific application requires conversation. What works for a B2B API won’t work for a consumer-facing mobile application. Threat modelling frameworks like STRIDE or PASTA provide useful starting points, but the SSA needs enough context about the business function, the users, the data sensitivity, and the deployment environment to conduct meaningful threat assessment. This is why meetings with application teams are mandatory rather than optional. You can’t threat model by email. The Risk Management Forum review in Step 8 introduces formal risk acceptance into the process. This is critical because perfect security doesn’t exist. Every application ships with residual risk, and someone with appropriate authority needs to acknowledge and accept that risk. The alternative—security teams identifying issues without clear risk ownership—creates a situation where findings get documented but never resolved, and everyone can later claim they weren’t responsible for the decision. The threat/risk scoring matrix provides a structured way to communicate severity without falling into the trap of treating all security findings as equally critical. The requirement for CISO approval when PHI or PII moves to the cloud in Step 10 reflects regulatory reality in financial services and healthcare. This isn’t security theatre—it’s acknowledging that certain data handling decisions carry legal and reputational consequences beyond technical security concerns. The CISO needs visibility into these decisions because they’re accountable for the organisation’s overall security and compliance posture. The trade-off is that this can become a bottleneck if not managed carefully. Clear criteria for what requires CISO review versus what the SSA can approve helps prevent everything from escalating. The Security Peer Review Forum in Step 12 addresses a problem I’ve seen repeatedly: individual architects, no matter how skilled, have blind spots. Peer review distributes the cognitive load of security assessment across multiple people with different backgrounds and experiences. It also creates consistency across assessments. When multiple SSAs are conducting reviews, peer forums help ensure that one architect’s risk appetite doesn’t significantly diverge from another’s. The challenge is making these forums efficient. If every review requires an hour-long meeting with six people, the process becomes unsustainable. The key is focusing peer review on novel architectures, significant risks, or cases where the SSA is uncertain about the assessment. Step 13—resolving design deficiencies—is where the rubber meets the road. The procedure creates a forcing function: the application team either commits to fixing issues before going live, or the risks get formally added to the enterprise risk register. This prevents the common pattern where security issues get identified, everyone nods seriously, and then nothing changes. The Corrective Action Report with timeline creates accountability. The enterprise risk register creates visibility. Neither is sufficient alone, but together they make it harder for identified risks to simply disappear into the backlog and never get addressed. The final peer review in Step 14 serves as a quality gate. It’s the SSA’s colleagues reviewing the SSA’s work product to ensure the assessment was thorough and the conclusions are sound. This protects both the organisation and the individual architect from assessment failures that only become apparent after incidents occur. The challenges of implementing this process are significant. It requires security architects with broad skills, application teams willing to invest time in documentation, and an organisational culture that treats security as a shared responsibility rather than a separate department’s problem. It requires executive support for risk acceptance decisions and consequences when risks aren’t properly managed. It requires tooling to track assessments, findings, and remediation timelines. Most difficult of all, it requires trust between security and application teams—trust that security is trying to help rather than obstruct, and trust that application teams will be honest about constraints and limitations rather than gaming the process. I’ve seen organisations try to implement security review processes without these foundations, and they typically devolve into either rubber-stamp exercises that provide false assurance or antagonistic relationships where security becomes an obstacle to be routed around. The procedures documented here are my attempt to avoid both failure modes by creating a structure that’s rigorous enough to actually assess risk but collaborative enough to remain sustainable. Whether it works depends less on the procedures themselves and more on the people executing them and the culture they operate within. ### Like this: Like Loading... https://islandinthenet.com/collaboration-over-compliance/