Skip to main content

Security issues in SCRUM

Last post 08:19 pm January 20, 2024 by Kristian Georgiev
6 replies
09:50 am April 8, 2015


I'm wondering how security issues are supposed to be handled in SCRUM.

Is the management of security issues informal (i.e. as to be adressed orally at the daily SCRUM) or formal with for example dedicated items in the Product Backlog for security ?

Thank you for your help on this mattter.

03:14 pm April 8, 2015

You may need to be a little more specific with 'security in scrum' to get some good answers that will help you.

I am going to assume you mean something along the lines of encrypting the data, which I think would be a task in the user story and it would also be part of the acceptance criteria. It is something that most likely should be added to the teams definition of done and done in full as the team goes. You don't want the concept of 'building in security in the final 2 sprints' - because everything you have done up until that point isn't potentially shippable and you don't have the security you need.

03:46 am April 9, 2015

As Tims say, security requirements should be (as all other non functional requirement) agreed on in the Definition Of Done. This doesn’t mean the DoD is a 1000+ page reference guide.

It can be as simple / informal as:
- we adhere to our company security policies defined in chapter 3 & 6,
- our product is capable to withstand general threads, but no provisions are made to handle a specific concentrated attack.

The key is that it is transparent for the Development Team, The Product Owner and possible the stakeholders what is covered. For a security critical application it must be possible to refer to an internal or external reference.

04:34 am April 9, 2015

> I'm wondering how security issues are
> supposed to be handled in SCRUM. 

The key consideration is whether or not the requirements can be implemented and validated by the Development Team. If they can, then they may be added as PBI's (e.g. so-called "abuser stories") assuming that regression testing can be automated and is therefore scalable. It's also reasonable to add constraints and observations to the Definition of Done. These may assert the qualities of security with which each increment is expected to conform.

Security requirements which cannot be implemented and verified by a Development Team belong neither on the Product Backlog nor in the Definition of Done. Examples may include assertions about the penetration of certain live systems, recovery, failover, and concerns that involve security support following a release. These often relate more to the qualities of the organizational environment into which the increment will be deployed, as opposed to the qualities of the deliverable increment itself.

09:32 pm January 19, 2024

Hello All,

I would like to raise this topic, due to some misunderstanding in my mind.

Lets say that a developer is approaching the Scrum Master, and informs him about his security issues concerns. 
How would we expect the SM to react in such occasions?

From what I understand, the ways for the Scrum Team to ensure satisfaction of security concerns , is to add them to the DoD, and having them added to the Product Backlog as a PBI.

According to the scenario above, does it mean that the Scrum Master should advise the developer to share his security concern with the Scrum Team, or wait till the next Sprint Retrospective, and raise the concern, which will lead to adding it to the DoD?

Some explanation would be highly appreciated.
Thanks in advance !

11:21 am January 20, 2024

As SM I would advise them to take it to the team. This time and in the future. SM doesn't need to be the middle-person or broker in raising such things.

DoD pertains to the Increment and could possibly include insuring that security scans are completed or that no security issues are knowingly introduced etc. to help protect the integrity of the product when integrating into the Increment. Sprint Retrospective is a good place to review and update the DoD. That said, if a need to refine (strengthen) the DoD presents itself, there is no need to wait and put off the adaptation. 

If there is an immediate security concern that needs to be addressed, beyond strengthening the DoD, waiting until Sprint Retrospective could be dangerous and impactful. Sprint Retrospective could be days or weeks away. Bringing immediate attention to the security concern supports transparency with which the team can inspect and adapt as needed to mitigate the concern based on what the team decides.

08:19 pm January 20, 2024

Hi Ryan,

Thank you for the good explanation ! 

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.