With GDPR, the California Consumer Privacy Act (CCPA), and other high-profile regulations making waves these days, privacy is a hot topic. Despite this, some security professionals may not immediately consider privacy to be relevant to their function within the organization.

In our recent webinar, Privacy by Design for the Security Professional, Baber Amin, CTO West at Ping Identity, and Andrew Migliore, RadarFirst’s VP of engineering and security officer, discussed where privacy best fits into the security ecosystem and what it means to take a privacy by design approach within the security and technology business units. The following Q&A with Andrew is a highlight of the insights to be gained from the webinar.

Priscilla Converse: Why should security care about privacy?

Andrew Migliore: To start with, both privacy and security have a common goal—to protect the organization from risk. That includes protecting personal information. Regulators are expanding the definition of personal information while reducing the timelines for breach notification worldwide. Certain laws also require you to handle requests from consumers who want control over their data. It’s impossible to effectively safeguard information without accounting for these privacy requirements.

Failing to comply with data privacy regulations is a major risk to your business’s bottom line, due to the potential loss of prospects and customers, as well as major fines for non-compliance. These risks mean that cyber and data privacy strategies are a board-level concern. In fact, the World Economic Forum rates a large-scale cybersecurity breach as one of the five biggest risks facing the world today, and the OWASP Top 10 Privacy Risks Project indicates that insufficient data breach response is the number three risk.

So when it comes to privacy incident breaches, it’s not if, but when. Security has to be concerned with privacy.

Priscilla: As a security professional, how can I improve privacy in my company? 

Andrew: If you have not already been meeting with your privacy counterparts, do so. The seven principles in the Privacy by Design framework, although not prescriptive, can help security and others consider how to integrate privacy throughout their organization. Some of the key principles include:

  • Proactive, not reactive; preventative, not remedial. This requires cross-team collaboration to work more efficiently, so you can proactively address privacy concerns.
  • Privacy as the default. Putting privacy front and center builds a sense of trust in your customers and others with whom you work.
  • Privacy embedded into design. If your product or service involves the use of personal data, consider privacy as you’re developing new projects or rolling out new policies.
  • Respect user privacy: Keep it user-centric. Make it easy for people to understand how you’re using their data.

Priscilla: How can you protect users’ privacy without having them agree to a giant privacy policy up front or asking for consent without giving them the context of how we will use their data? 

Andrew: Great question! Users want to know exactly what data elements your business is using and for what purpose. It’s important to understand the real challenge isn’t accepting a user’s consent—it’s enforcing it. Consent has to be flexible, auditable, and transparent to users. The role of identity comes into play here. How do you verify the identity of the subject/user to properly enforce privacy concerns? One way is to build a consent schema right into the user’s profile. Users can have multiple consents for the same element or data elements, different applications, entities, or partners. This type of consent capture and enforcement allows you to deliver a better privacy experience to your customers. What’s more, it embraces important privacy by design tenants, such as respecting the user’s privacy.

Priscilla: Why is cross-team collaboration so important?

Andrew: Traditionally, security has mostly concerned itself with the electronic perimeter. If you think about it, though, privacy is a superset of security. CISOs and other security professionals need to be able to quantify all areas of organizational risk—both electronic and non-electronic, such as verbal, visual, and paper—as well as understand the context in which a privacy incident occurs. The best practice is to capture all privacy incidents with their root cause and report on them. Then you can make appropriate changes to processes to improve your company’s overall privacy program.

Priscilla: How can I measure the effectiveness of my privacy program?

Andrew: In the world of privacy and security, you can’t manage what you don’t measure. The overall goal should be reducing the overall time it takes for security and privacy to perform the handoff and a privacy risk assessment to be performed. Incident response metrics should include:

  • Mean time to detection (MTTD) – Average time it takes from incident occurrence to detection
  • Mean time to assessment decision (MTTAD) – Average time it takes from assessment to make a breach or no breach notification decision
  • Mean time to notification (MTTN) – Average time it takes to notify after the first decision is made

The key metric that spans both security and privacy is meantime to privacy response (MTTPR). This is the average time it takes from detection of a privacy incident to when a risk assessment is performed. This assessment quantifies the risk of harm to individuals and the organization. If you look at the trend toward reduced notification timelines for both regulatory and contractual obligations, this is the next logical area for security and privacy to measure and improve.

Privacy automation is key here. Using software to risk score privacy incidents and determine notification obligations in an automated and consistent fashion greatly reduces the time it takes for a business to respond. It also reduces the reliance on outside counsel, which is often the main delay in being able to respond quickly.

Priscilla: Definitions of personal, sensitive, confidential, etc. data vary wildly depending on the country, region and company. Is there a governing body, framework, or commonly accepted definition I can reference?

Andrew: No, the jurisdictional definitions in regulations are what you should be paying attention to—and unfortunately, that’s where the complexity lies. Regulations are constantly changing, and each is unique. To maintain regulatory compliance, every organization that handles personal data should have a tool, such as Breach Law Radar, that provides continuously updated information on existing and proposed breach notification laws.

Priscilla: Mention was made of the existence of a “trigger” threshold for reporting of incidents. How and by whom are these determined—are data breaches not subject to mandatory reporting and notification irrespective of the number of data subjects and volume of information involved?

Andrew: Nope. The regulations vary by jurisdiction, and each will have different requirements for what constitutes a notifiable incident. In terms of data subjects involved, there are specific requirements in many jurisdictions that if x number of records are exposed (the threshold), you are required to notify the state’s attorney general, for example. Even the Office for Civil Rights (OCR) has a minimum number before it must be reported to the OCR Portal (the so-called “Wall of Shame”). In terms of volume of information, the real thing to pay attention to is the sensitivity of the data disclosed, and the likelihood that disclosure of the data could result in harm to the individual.

Discover more insights from Andrew and Baber by viewing the on-demand webinar, Privacy by Design for the Security Professional.


Read other articles our CISO blog series: