When developing software, whether employing the older waterfall methodology or one of the new agile methodologies, everything starts with requirements. No requirements, no software.
When developers think about turning requirements into software, what they primarily think about are functional requirements. Functional requirements describe, in detail, what the software is supposed to do. But there is another category of conditions that is just as important: non-functional requirements.
Non-functional requirements in software development
Non-functional requirements focus more on how than what. “Broadly, functional requirements define what a system is supposed to do, and non-functional requirements define how a system is supposed to be.”
What are some examples of non-functional requirements? They include things like availability, usability, performance, and security. There is another category of non-functional requirements becoming even more critical today and impacting software development. This category is referred to as GRC, which stands for governance, risk, and compliance. It’s not just businesses that have to deal with GRC; the software does as well.
Today, software not only has to process data according to its functional requirements, but it must also govern and protect that data in accordance with its non-functional requirements. And many of these non-functional requirements are required by law and depend on the industry and locality in which the software will be used. Examples include HIPAA for software used in the medical industry, GDPR for software processing user data in the EU, and PCI-DSS for software dealing with credit card transactions.
As part of the DevOps process, software engineers understand incorporating functional requirements into their software using various programming languages and controls. However, they may not be apparent on how to address the non-functional requirements, particularly those derived from GRC. And this is where commercial threat modeling tools can help.
How threat modeling can help with GRC
Everyone who uses threat modeling tools understands that those tools are used to model security threats. But the most modern threat modeling tools can also be used to model GRC “threats.”
Today, there are threat modeling tools that come complete with a library of built-in regulatory compliance frameworks. These frameworks, in the form of DevOps environments and software components, enable software developers to track the software’s adherence to specific GRC requirements throughout the SDLC from inception to production. This gives the reassurance compliance is woven into the foundation of design.
Keep in mind that most software developers are not GRC experts. So, not only do developers now have tools available to them that enable them to address mandatory GRC requirements, but it also alleviates them from having to figure out how to realize those requirements in the software.
In addition to meeting current GRC requirements, a flexible GRC framework also helps developers to more quickly and easily adapt to rapidly-changing GRC requirements. If you’d like to learn more about how you can outsource your GRC software requirements to a modern threat modeling tool, request a live demo of Threat Modeler.
