“I don’t want to be on the news, or the witness stand.”

This is the tongue-in-cheek mantra I sometimes express to my staff.  While it is intended to be humorous, it does quickly express some of the negative outcomes that CISO’s seek to avoid.  Certainly, a large breach or incident is a fast lane to either – but running afoul of privacy regulations is another.

There is no doubt that SecDevOps improved not only the inherent security within our code and application environments, it also clearly fostered partnerships and growth within all the teams involved.  Developers are far more likely to leverage static code analysis tools and secure coding best practices, to improve both their code and their skills.  Security and Operations teams are better able to plan changes to security policy and architecture, and to schedule security and quality testing, all while keeping to release timelines.  These improvements and more should be familiar to those who have implemented a SecDevOps model.

However, in a CISO role, it is quite common to work closely with the Legal \ Privacy and Enterprise Risk Management teams as well.  Having had a major role in projects like GDPR and new ERM implementations, I can’t un-see the risks and stakeholder obligations that these teams attempt to manage.  In fact, as CISO, we are likely to be their closest technology partners in the organization (Chief Counsel at my organization thinks I secretly wanted to go to Law School – maybe he is not wrong).  So, maybe it wasn’t a surprise when I asked at a SecDevOps meeting, whether the business requirements accounted for any changes to Risk or Privacy Control Frameworks – the two major initiatives I had spent the last year trying to get under control.

In truth – this information needs to be collected at the business requirements phases – but the implementation teams need to account for these requirements as well.  Where can collected data elements be stored?  Does this data need to be encrypted or tokenized? Do the transactions, functions or features added require any changes to our existing control framework?

To address these questions, I propose an expansion of SecDevOps to include Privacy and Risk Management as well – I call this framework (Code) D.R.O.P.S.

Development, Risk, Operations, Privacy and Security.

Now, the order does not imply importance or sequence.  Frankly D.R.O.P.S was just the best sounding acronym I could construct.

We all now realize that privacy must be baked into the development process – this is the heart of Privacy by Design.  But Risk – beyond just cybersecurity – must also be addressed proactively.  While SecDevOps certainly was a step in the right direction, inviting and considering these other functions in the development process is critical as well.

(Code) D.R.O.P.S spins out of the requirements gathering phase, and can begin with some simple check gate questions.   Some basic examples can include:

1. Are we collecting, processing or sharing any (new?) private data?  And if yes:
   • What was the basis for doing so (consent, legitimate use, etc.)?
   • What level of access controls, encryption or tokenization is needed?
   • Does this data get shared outside our organization or cross borders?
   • How long can we retain this data?
   • How would we respond to (data subject) requests regarding this data (including the “right to be forgotten”)?
2. Does the requested functionality introduce or change our existing organizational risk level? If yes:
   • How could these new or changed risk scenarios (things that could go wrong) impact our:
     • Reputation
     • Operations
     • Financial position
   • How likely are these risk scenarios to occur (within a three year time frame)?
   • What controls do we have, or need to implement, to mitigate this risks from occurring?
   • How, and how often, do we need to test these controls?

With these answers, security, operations and development teams can propose, budget and implement their solutions to address these concerns during the development process itself.

Ironically, the post release consideration of cybersecurity was exactly what SecDevOps was created to avoid.  We know addressing security issues is far more expensive and disruptive in production.  Implementing remediations diverts resources from all teams in the process – let alone the real risks to which the organization was exposed (and which we hope were not exploited in the meantime).  As CISO’s, we should work to ensure that privacy and enterprise risk are addressed in a similar, proactive manner.  More than likely, we are already the technical partners that these teams interact with most – both as their advocates, and the most likely to inherit the fallout of not addressing their concerns.

(Code) D.R.O.P.S hopes to keep us off the witness stands and out of the news – for ALL the reasons we can reasonably foresee.