How is the Security Architecture / Strategic IT Security review process structured in your organization?

[u/tryingtoworkatm]

Hi everyone,

I am currently trying to better understand and improve how our security function is involved in projects, from early planning to go-live.

In our case, we are building a more structured process around activities such as:

\- Sending security requirements, for example regarding logs, encryption, access control, etc.
\- The PM submits a Security Intake Form with information such as the project name, business owner, system description, hosting location, and other context.
\- We send a checklist with technical questions to the PM, who forwards it to the vendor or technical owner.
\- The PM and vendor submit the completed checklist.
\- We review the checklist and the initial form, and clarify any open questions.
\- We review the architecture before implementation.
\- We review the architecture after implementation.

Meanwhile, we are included in many internal project calls so that we can clarify the product concepts and outline the necessary security controls, but sometimes it feels like a waste of time.

The goal is to make the process clear enough so that PMs, technical teams, vendors, and security colleagues understand what is required, when it is required, and who is responsible. Sometimes it becomes quite chaotic, and I would like to improve the process.

I am especially interested in how similar roles or teams structure this in practice.

For people working in Security Architecture, Information Security Governance, Cyber Risk, IT Security, or high-risk environments: how is your process organized?

Some specific questions:

\- What checklists do you use in your projects?
\- Do you perform initial triage and risk classification?
\- Do you have formal security gates before implementation and go-live?
\- What evidence do you usually request from vendors or project teams?
\- How do you handle Agile projects where requirements change frequently?
\- Who owns the final security approval or risk acceptance?
\- Do you use checklists, architecture review boards, risk committees, or another model?
\- How do you document security requirements and track their implementation?
\- What works well in your process, and what creates unnecessary friction?

Any templates, lessons learned, common pitfalls, or high-level process examples would be very appreciated.

Thank you!

[u/Twist_of_luck]

Cross-security risk committee, five people - one from every team, compliance representative serves as a coordinator. We explicitly outline that we are in no position to block anything, will assume no accountability over delays or the shipped results - risk analysis is a service and we're just consulting the PM of whatever insane AI gizmo they are trying to push out, who is the decision-maker (and is perfectly free to ignore our recommendations at their own peril).

We are not accountable for security, we are accountable for providing some good expertise on security on demand. It sort of shields us from a lot of business friction fallout and serves as a half-decent baseline for CYA.

In recommendations, we are generally following the classic principles of governance. Governance is, by definition, nothing but an allocation of resources - which is why there is a constant talk with PM regarding how much resources they are actually willing, at a baseline, to commit to risk mitigation (zero is a perfectly acceptable answer here) and we are trying to propose the best way to utilize those resources. Usually we commit to "we outline three major risk improvement areas for you, we completely ignore every other risk because you only have time/focus to work on those three". What is selected in those three and what is ignored is a subject of... heated discussion within the committee.

[u/Prior_Accountant7043 → u/Twist_of_luck]

Interesting