What a Security Architect Actually Does: Three Roles and Where Requirements Come From

A security architect does three jobs: sets security requirements for systems other people design, assesses and reviews those designs, and solutions security-specific systems end to end from requirements through deployment and verification. Underneath all three sits one skill that defines the role, deciding what a system must do to be secure and writing it down as a requirement. This is my own account, from doing the work, of what the job involves and where good security requirements come from.

The three roles of a security architect

A security architect's work falls into three buckets, and confusing them is why the role is so often misunderstood. Naming them separately makes it clear which one a given piece of work belongs to.

The first role is advisory: the system exists to serve a business purpose, and the architect supplies the security requirements it must meet. The second is assurance: the architect reviews the design and, after build, verifies that what was designed was implemented. The third is delivery: for security-specific systems the architect ends up solutioning the whole thing. The security architecture review process sits inside the second role, and security architecture advisory spans the first and third.

Does the security architect help implement, or just design?

Ideally the security architect stays involved through implementation, because a design handed off and never checked drifts from what was intended. The architect does not need to be hands-on keyboard deploying the system. The job is to consult the engineers doing the build, because they are the ones implementing what was designed, and to answer the questions that come up when the design meets reality.

Start with discovery of the systems in scope

Always start with discovery of the systems in scope, both the ones that exist today and the ones still being planned. Before you can source a single requirement, you need an accurate picture of what you are securing: the applications, the infrastructure, the data flows, and the integrations, plus anything on the roadmap that the design has to accommodate. A requirement written against a system you have not actually mapped is a guess.

Discovery is what keeps the rest of the work honest. It defines the boundary the requirements apply to, surfaces the connections and data stores that carry the real risk, and catches the planned system that would otherwise be secured only after it is already built. Skip discovery and you write requirements for the architecture you imagine rather than the one you have.

Where do security requirements come from?

Security requirements come from five sources: compliance and regulatory obligations, established best practice, the non-functional requirements any system needs, threat modeling of the specific system, and the operators who will run it. Knowing which source a requirement came from is what separates a considered design from a copied checklist.

The highest-level source is formal compliance: regulatory requirements such as HIPAA, GDPR, and PCI DSS, and commercial standards such as ISO 27001 and SOC 2. These sit above the technical detail and set obligations the design must satisfy, for example that access is controlled, that data is encrypted, or that activity is logged and reviewed. The lower-level threat and technical requirements map up to them: a threat functional requirement to detect and block SQL injection is evidence toward an ISO 27001 or SOC 2 control, and a rule that enforces encryption in transit maps to a HIPAA or PCI obligation. Sourcing the compliance requirements first, then mapping the detailed requirements up to them, is how a design satisfies an auditor and an attacker at the same time.

The second source is industry best practice, the common body of knowledge about what makes systems secure. Multi-factor authentication is the standard example: you do not need to threat-model or debate it, because it is settled good practice. A large share of any design is simply applying the established body of security knowledge to each component and each connection. The remaining sources, non-functional requirements, threat modeling, and operator needs, are where the system-specific design work happens, and they differ depending on whether the system's purpose is security or something else.

How requirements differ for business systems versus security systems

The source of requirements depends on whether the system's purpose is security or something else, and the split is the most useful distinction in the whole role. Get it wrong and you either under-secure a business system or fail to specify what a security system is actually for.

For a business system, a web application or a database, security is a non-functional concern, because the system exists to do something else. Most of its security requirements are non-functional: authentication, role-based access control, secure configuration, cryptography for confidentiality, logging so activity is recorded, and so on. You walk the cybersecurity body of knowledge and apply the relevant best practice to each component and connection.

For a security system, a firewall, a SIEM, or a privileged access management platform, you do all of that and then add a second layer the business system never needs: requirements for the security function the system exists to perform. Securing the tool like any other system is table stakes. Specifying what threat it must defend against is the actual point of the exercise.

What are threat functional requirements?

Threat functional requirements are the requirements written for a security system that specify the threats it must detect or prevent. They are the requirements that only exist because the system's job is defense, and they are the clearest marker of a security architect who understands the second layer.

A web application firewall (WAF) is the clean example. Because the concern is SQL injection, cross-site scripting, and similar application attacks, you work through the OWASP Top 10 and comparable sources and write that the WAF must detect and prevent injection, cross-site scripting, and the rest. Each threat you are worried about becomes an explicit requirement the tool has to satisfy. This is where application security requirements get concrete: not a vague ask that the WAF should be secure, but a specific requirement that it block this class of attack.

Why you must design for the people who operate the system

A security system also needs operational functional requirements, because a tool the security operations center cannot run does not defend anything. After the threat functional requirements, the architect interviews the people who will use the system, chiefly the security operations center (SOC), and writes requirements for what they need to do their job.

For the WAF, the SOC needs to create detection and prevention use cases, block user-agent strings, take defensive actions, and capture packets for investigation. Packet capture is worth pausing on: it does not prevent an attack, so it is not a threat functional requirement. It exists so operators can investigate potential attacks after the fact, which makes it an operational functional requirement. Getting that classification right keeps the design honest about what each requirement is for. The same logic drives a good logging and monitoring architecture: the point is to give operators what they need to investigate, not only to block.

The full requirement set for a security system

A security system needs three kinds of requirements at once, and a design missing any one of them ships a tool that is insecure, ineffective, or unusable. Laying them side by side is the fastest way to check a design is complete.

The security system must be secured like any other, which is the non-functional layer: administration needs MFA, and the WAF's own audit logs need to be generated and fed to the SIEM. It must perform its defensive function, which is the threat functional layer. And it must be operable by the SOC, which is the operational functional layer. All three, every time, for any security-specific system.

What to take from this if you are building or hiring for the role

1. Start with discovery. Map the systems in scope, existing and planned, before sourcing a single requirement. A requirement written against a system you have not mapped is a guess.
2. Separate the three roles when you scope work. Securing others' systems, reviewing and verifying, and solutioning security systems are different jobs. Be clear which one a task is.
3. Do not skip verification. Write the definition of done at the start, and after the build confirm the design was implemented before the system goes to operations.
4. Classify every requirement by source. Compliance obligation, best practice, non-functional, threat model, or operator need. If you cannot say where a requirement came from, question whether it belongs.
5. Source the compliance obligations first, then map up to them. Start from the regulatory and standards requirements (HIPAA, GDPR, ISO 27001, SOC 2), then map the detailed threat and technical requirements up to those obligations so the design satisfies the auditor and the attacker at once.
6. For security systems, write all three requirement types. Secure the tool, specify the threats it must stop, and specify what operators need to run it.
7. Interview the operators. The SOC is a client of every security system. Their operational requirements are as real as the threat requirements, and they are the ones most often missed.

Frequently Asked Questions

What does a security architect do?

A security architect performs three roles: setting security requirements for systems others design, reviewing those designs and verifying the build against a definition of done, and solutioning security-specific systems such as SIEM, PAM, or a WAF from requirements through deployment. The common thread is translating a broad ask to make it secure into specific, sourced requirements.

Where do security requirements come from?

From five sources: compliance and regulatory obligations (HIPAA, GDPR, ISO 27001, SOC 2), established industry best practice, the non-functional requirements any system needs, threat modeling of the specific system, and the operators who will run it. Compliance is the highest-level source and the detailed threat and technical requirements map up to it. Best practice covers settled items like multi-factor authentication, while threat modeling and operator interviews produce the requirements unique to the system being designed.

What are threat functional requirements?

They are requirements written for a security system that specify the threats it must detect or prevent. For a web application firewall, working through the OWASP Top 10 produces requirements to detect and prevent SQL injection, cross-site scripting, and similar attacks. Only security systems have them, because only their purpose is defense.

How do requirements differ between a business system and a security system?

A business system treats security as a non-functional concern: authentication, access control, configuration, and logging applied to a system whose purpose is something else. A security system needs all of that plus two more layers, the threat functional requirements for what it must defend against and the operational functional requirements for what its operators need.

Does a security architect get involved in implementation?

Ideally yes. The architect does not have to deploy the system hands-on, but stays involved to consult the engineers doing the build and to verify, after the build, that the design was implemented against the definition of done. That verification step, done before the system moves to operations, is the one teams most often skip.