A formal design step in your development process can help a team achieve the compliance goals that governments and industry regulators require.
More and more, the software industry is seeing regulation imposed by government and industry bodies. This is something which is intended to improve our track record in achieving security, because it has been so poor. The sheer number of data breaches and security vulnerabilities announced annually is surely testament to this.
Formalising the design process can result in a deliverable that can be used to demonstrate to auditors that we are considering the security of our systems. This often goes a long way to preparing for the day when an audit takes place.
It is not uncommon for members of a development team to think of auditing very negatively. They consider compliance to be a barrier to them achieving their jobs. Any steps taken to achieve audit compliance are simply box-ticking exercises to be shortcutted or avoided. However, I think this is the wrong mindset.
Auditors ask us to undertake certain processes because they have been demonstrated to help protect the customers, company and employees. Their desire for us to consider the confidentiality, integrity and availability of data and the systems that handle it not because it is good for the auditor, but because it is good for the stakeholders.
Compliance is not about ticking boxes, it is about improving the way we protect the needs of the stakeholders.