A Visual Look at Privacy Architecture from a Security Perspective

 Cyber & Risk

I’m tired of 4 letter acronyms, specifically GDPR and CCPA. Here’s hoping we can have four-letter acronyms for each of the 50 states to memorize! Following California’s introduction of CCPA, a number of other states now have privacy laws in various stages of the legislative process. And let’s not forget about the new privacy rules being introduced on a global level.

Don’t let my dislike for acronyms fool you: it’s a very good thing that privacy is being highlighted, even if it’s being driven by legislation. But meeting privacy regulatory requirements shouldn’t be the primary goal of a privacy program – actually improving and ensuring privacy should get top billing. There are a number of areas that contribute to effective privacy, but security in particular can have a significant impact on privacy program success. Security helps organizations “walk the talk” on privacy and while privacy isn’t security and security isn’t privacy, there are notable overlaps across the two disciplines.

Privacy Architecture

Sila built the following privacy architecture diagram to illustrate how and where security can provide support to organizational privacy objectives. The architecture depicts a number of privacy areas, key relationships between them, and specific areas in which security can play a role. The diagram moves from right-to-left (starting with governance) as well as left-to-right (processing internal and external requests), meeting in the middle around data protection.

Based on this mapping, security can take the following four approaches to assist a privacy program.

privacy architecture

Establishing Structure (Governance, Policies, Procedures, Controls)

Organizational legal teams are adept at identifying regulatory rules and impacts to their specific industry or enterprise. The next critical step, however, is best done in concert with security: translating the legalese into actionable policies, procedures, and controls for the organization to implement.

Data Determination (Categorization, Mapping, Risk & Impact Assessment, Incident Management)

The first two items in the CIS CSC top 20 controls, ordered in recommended priority, are related to asset management. This is no different with data, which is an asset: it’s difficult to protect what you don’t know exists. The determination of how to protect data should be driven by risk, specifically looking at it from the point of view of an impacted individual. There is a higher expectation of breaches now, but what sometimes hurts organizations more than the breach itself is how they handled the incident, both internally and externally.

Processing Requests (Internal, External, Third Parties)

There’s more to processing privacy requests than data subject access requests (DSARs), even though managing an increase in DSARs is an immediate need for many organizations. Processing in this context is less about the ability to take in and respond to a request and more about the privacy and security scrutiny being applied to the request process. There are a variety of processing needs and requirements to review from both internal sources (i.e., collecting new data sets) to external sources (i.e., managing third parties and the data they have access to).

Communicating Privacy (Training, Communication, Change Management)

Security can’t support privacy in a vacuum. Creating an effective privacy program is a significant organizational change and benefits from training and communications initiatives from a security perspective. From the three lines of defense to your customers and third parties, privacy affects each of your organizational relationships.

Security Principles for Privacy

The four approaches above outline how security can add value to a privacy program. Each of them should also be reviewed with the following three principles in mind.

  • Privacy by Design: The practice of embedding privacy into underlying processes, objectives, operations, and technologies by default
  • Security Engineering: Using security engineering best practices and the implementation of controls in support of privacy requirements
  • Operationalization: Incorporating reusable practices so that privacy practices are repeatable and automated; long-term privacy requires sustainability

Adding Value

Privacy needs are not going away. They are only growing. Yes, they are driven by rules and regulations, but those rules and regulations are driven by privacy principles that many organizations have overlooked. The three questions below will help you better understand if your security team is currently adding value to your privacy program:

  • Review how your security team is currently providing support to your privacy program. Compare that support to the privacy architecture diagram. Are there areas that are not being supported by security? How could they add value to your organization?
  • Look at the last three large technology initiatives at your organization. Were privacy by design recommendations made at the beginning, middle, end, or never provided? What impact did or could they have had on the respective projects?
  • Review the processes and technologies that both the business units and the privacy team use to provide privacy support. Is the process simple and well known? If there was an influx of requests, would you be able to scale without adding additional staff members?

About the Author

matthew karnas

Matthew Karnas is the Cybersecurity & Risk Practice Lead at Sila. He has 18 years of experience providing professional services to Fortune 500 companies and government agencies across multiple verticals. He brings a unique mix of both technical and functional experience advising on information technology, cybersecurity, and risk management practices and approaches to drive client successes.