Security and Compliance Review

26 ap-security-and-compliance

As a step in the overall Portfolio Kanban, Security and Compliance leadership review Epics to ensure that additional scope in the areas of Security or Regulatory Compliance are included within the Epic definition.

Explore More.


Epics with a defined business case


Updated Epics that include necessary work around security and regulatory compliance

Many organizations struggle to integrate concepts such as Security and Regulatory Compliance within an agile workflow.

Most organizations follow a waterfall process for this type of review, which requires either a complete Business Requirements Document (BRD) or an implemented Feature to review. To properly integrate within an agile process, organizations will need to embrace a process where reviews happen at multiple places within the process with Security and Compliance leaders working collaboratively with Business and Technical leadership to identify areas of concern with functionality defined within agile documentation.

“When creating a new model to merge agile and risk management worlds, it is important to stay loyal to agile manifesto and lean principles.”1

In a modern agile paradigm, all resources are aligned around a “business outcome mindset”. Within this mindset, the Security and Compliance leaders are valued members of the team within the Agile Portfolio and Program segments.

“As part of the transition to supporting a business outcome mindset, IT risk and security leaders must move from being the righteous defenders of the organization to acting as the facilitators of a balance between the need to protect the organization and the need to achieve desired business outcomes.”2

Part of the planning that may occur at this level relates to automated testing, which will occur later in the process. Automated security testing has become a staple of enterprise organizations. If an Epic introduces a new area of functionality which will require a new type of testing, a technical enabler3 can be created within the Portfolio for that functionality. The end goal should be a workflow that is consistent with the Continuous Delivery Mindset.

Common Pitfalls

While many organizations have both security and compliance workflows within their workflow, there are common pitfalls which should be avoided:

  • Additional work not identified within Epics: The reason for exposing Security and Compliance leaders within both the Agile Portfolio and Program levels is to ensure that work needed to support organizational standards and guidelines is identified early in the process and may be scoped, estimated, and planned with the rest of the work. If an organization is still surfacing additional work once a Feature is complete in this area, additional reviews will need to be integrated throughout the process.
  • Lacking clear guidelines for Security or Regulatory Compliance: Mature organizations should have clear and comprehensive guidelines for these areas already defined. It is understood that these guidelines will be constantly evolving, but the validation within the Portfolio segment should mainly consist of comparing an Epic against existing guidelines.
  • Large lead times for Security and/or Compliance Reviews: Within the Portfolio segment, this element sits within the Portfolio Kanban process. While this process allows for work steps of variable times, the focus is still on the flow of items from entry to exit. While the amount of time required for this review will be dependent on several factors, it should be measured in days, not weeks or months.