Framework core concepts

Accountability & Responsibility

Security programs fail when they don't communicate clear, fair, scalable accountabilities and responsibilities. In the PSCF, we define accountability and responsibility and how they are most effectively used.

Defining accountability and responsibility

It's essential to be clear about who is accountable and who is responsible for security capabilities. Equally important is that everyone in your organisation understands what being accountable and being responsible means. In the PSCF we use the definition from McGrath & Whitty's 2018 paper, "Accountability and responsibility defined" in the International Journal of Managing Projects in Business.


Accountability: liability for ensuring a task is satisfactorily done.

Accountable : having liability for ensuring a task is satisfactorily done.

Only individuals can be accountable. If more than one person is accountable, then no one is.


Accountability is what happens after a situation occurs. It's who responds and takes ownership.


Responsibility: an obligation to satisfactorily perform a task.

Responsible: accepting an obligation to satisfactorily perform a task.

Groups of people can be responsible. In software development many people are often required to collaborate to satisfactorily perform a task.


Every person on a team may be responsible for a task that’s required to complete a big project.

Fairly and scalably assigning accountability and responsibility

To be fairly held accountable or made responsible for a security capability's tasks, the individuals or groups need a minimum level of Understanding, Information and Opportunity. When this is not understood or taken into account, organisations end up with very low security capability effectiveness.


To be held accountable for ensuring a task is satisfactorily done, you don't need to understand the task well enough to carry it out yourself (Understanding level 3+) but you do need to understand the task well enough to identify that it is being done satisfactorily (Understanding level 2).


You also need information that shows you whether the task is being carried out at all and that the results of the task meet requirements. This information could take many forms and could be a dashboard, a regular report or visual confirmation in some cases.


The more things you're accountable or responsible for the more of your time it will take to deal with these things. If the people being held accountable or responsible simply don't have time to do everything they need to do then the organisation's expectations are not fair or scalable.

You need accountabilities and responsibilites that scale at least linearly as the organisation grows. With good use of automation and data presentation, you can achieve sub-linear scale as the organisation grows.

The most important aspect of opportunity for accountability is related to tools. A tool not often recognised is the tool of setting work priorities. An accountable person must be able to set work priorities for the responsible group. Without that tool available, they cannot be held liable for ensuring a task is satisfactorily done.

If you have a person accountable for security desperately trying to persuade the responsible groups to do the security tasks they're responsible for, then you have a big problem.

Getting it wrong

A common mistake organisations make when implementing a software product security programme is to make a central application security team responsible for security tasks and a head of application security accountable for the security of delivered applications. This is neither fair nor scalable. A central appsec team can be an enabling team, but responsibility for security tasks must sit with the product delivery teams, and accountability for a software product's security must be with the product's lead decision-maker.

Suggested accountabilities and responsibilities

This framework comes with suggested fair and scalable accountabilities and responsibilities for all security capabilities. These suggestions are based on a product- or stream-aligned scalable team structure such as defined in the Team Topologies approach. If your delivery organisation is structured in this way, then you should be able to adopt these as they are. If your organisation has a different structure, then you will have to adapt them for your purposes.

Bear in mind the guidance given in this section when you do this. Be rigorous in ensuring that accountabilities and responsibilities are fairly and scalably assigned or your product security programme will fail to be effective.

Understanding, Information & Opportunity