GDPR Right to Be Forgotten and Other Access Rights

by | Oct 31, 2019 | Best Practices, Data Dictionary, Oracle DBA, privacy

GDPR is complex, and this post deals with only a small part of the law. GDPR is comprised of 99 Articles, of which three (Articles 15, 16 and 17) deal primarily with a consumer’s right to “be forgotten.” This includes the right to access the data that your business keeps about them (Article 15), the right to have incorrect information about them fixed (Article 16) and the right to delete information that your business has collected about them (Article 17).

A summary of the requirements of these GDPR Articles appears at the end of the post. However, the purpose of this article is not to explain these requirements, but rather to suggest approaches that your technology team can take to facilitate compliance with them.

Technical approaches to facilitate compliance

To ease compliance with Article 15, 16, and 17 of GDPR, and to support compliance with other GDPR Articles, we recommend the following steps with regard to handling of personal data. This is not intended to be a comprehensive list of everything you need to do to comply with GDPR. Instead, we see these as best practices to make compliance easier to achieve and more likely to be adhered to. Many of these steps are important for general data security as well—so even if you are not subject to GDPR these are good practices to follow.

  1. Keep an up-to-date data dictionary (metadata) that clearly identifies the location and meaning of all data elements that contain personal data (see definition below). From a GDPR perspective, it will be helpful to keep the following information in this dictionary. This will help when creating your privacy policy.
    • Name of the data element (column name)
    • Where the data element is stored (database name, table name)
    • The meaning of the data element
    • What the data element is used for in the system (i.e., the business reason for needing it)
    • How the data element is collected (what screen or input file)
    • The Personal Data Category from the GDPR regulation (see Article 15 below)
  2. This data dictionary must be updated each time the database is modified to add or remove data elements, or to change the meaning or use of an existing data element (which is not a good practice, but that is a topic for another blog)
  3. Create a set of data entry screens that customer service staff can use to easily perform the actions required under these GDPR articles. These screens can call stored procedures (recommended) or other code that does the work of gathering or modifying the information, and keeping a record of it when appropriate. Using a data entry screen rather than the command line allows a customer service representative to perform these actions rather than relying on manual steps by a developer or DBA. Note that all requests of this type should be validated by sending an email back to the recipient and waiting for confirmation before complying. These screens would call the following:

To support Article 15 — Access

Stored procedures to query all data for an individual, in order to comply with requests from an individual for the data you have about them. By providing this data in a machine-readable format, this can also support compliance with GDPR Article 20 (data portability).

To Support Article 16 — Rectification

One or more stored procedures to query a given user and to modify any personal data that an individual might request.

To Support Article 17 — Erasure

A stored procedure that will cleanly remove all personal data for an individual, as well as related data if the removal of personal data renders any remaining data for an individual useless. If you are using a relational database that has the capability, we recommend creating cascading delete constraints or triggers so removal of related data is simple, safe, and automatic. It is important not to log the removal of any personal data if the log would contain any of the data that was removed.

Depending on your business requirements, there is an alternate technical approach that can help you comply with the Article 17. GDPR requires that data be removed upon request, but that only applies after any legal obligation that your company has to keep the data. For example, if you have to keep contracts for seven years for tax purposes, then you do not have to comply with a request for erasure until that period passes. So an alternative approach to complying with Article 17 would be to write maintenance software that automatically removes all personal information from your system after legal obligations no longer require it. This removes some historical reporting capability, so it may not be appropriate for your business.

Details about the referenced GDPR Articles

The following information about the GDPR right to be forgotten and other rights mentioned above is taken directly from the GDPR recitals as published here: https://gdpr.eu/. In some cases I changed the structure to make it a bit easier to understand the rules.

Pertinent Definitions

  • Personal data means any information relating to an identified or identifiable natural person (“data subject”). An identifiable natural person is one who can be identified, directly or indirectly; in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or mor factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person.
  • Processing means any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organization, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction.
  • Controller means the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data, where the purposes and means of such processing are determined by Union or Member State law, the controller or the specific criteria for its nomination may be provided for by Union or Member State law.
  • Processor means a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller.
  • Recipient means a natural or legal person, public authority, agency or other body, to which the personal data are disclosed, whether a third party or not. However, public authorities which may receive personal data in the framework of a particular inquiry in accordance with Union or Member State law shall not be regarded as recipients; the processing of those data by those public authorities shall be in compliance with the applicable data protection rules according to the purposes of the processing.

Article 15: Right of Access By The Data Subject

The data subject shall have the right to obtain from the controller confirmation as to whether or not personal data concerning him or her are being processed, and, where that is the case, access to the personal data and the following information:

  • the purposes of the processing;
  • the categories of personal data concerned;
  • the recipients or categories of recipient to whom the personal data have been or will be disclosed, in particular recipients in third countries or international organizations;
  • where possible, the envisaged period for which the personal data will be stored, or, if not possible, the criteria used to determine that period;
  • the existence of the right to request from the controller rectification or erasure of personal data or restriction of processing of personal data concerning the data subject or to object to such processing;
  • the right to lodge a complaint with a supervisory authority;
  • where the personal data are not collected from the data subject, any available information as to their source;
  • the existence of automated decision-making, including profiling, referred to in Article 22(1) and (4) and, at least in those cases, meaningful information about the logic involved, as well as the significance and the envisaged consequences of such processing for the data subject.
  • Where personal data are transferred to a third country or to an international organization, the data subject shall have the right to be informed of the appropriate safeguards pursuant to Article 46relating to the transfer.
  • The controller shall provide a copy of the personal data undergoing processing. For any further copies requested by the data subject, the controller may charge a reasonable fee based on administrative costs.
  • Where the data subject makes the request by electronic means, and unless otherwise requested by the data subject, the information shall be provided in a commonly used electronic form.
  • The right to obtain a copy referred to in paragraph 3 shall not adversely affect the rights and freedoms of others.

Article 16: Right to Rectification

The data subject shall have the right to obtain from the controller without undue delay the rectification of inaccurate personal data concerning him or her. Taking into account the purposes of the processing, the data subject shall have the right to have incomplete personal data completed, including by means of providing a supplementary statement.

Article 17: Right to Erasure (right to be forgotten)

When does the right to be forgotten apply?

  • where the personal data are no longer necessary in relation to the purposes for which they are collected or otherwise processed
  • where a data subject has withdrawn his or her consent or objects to the processing of personal data concerning him or her
  • where the processing of his or her personal data does not otherwise comply with this Regulation
  • That right is relevant in particular where the data subject has given his or her consent as a child and is not fully aware of the risks involved by the processing, and later wants to remove such personal data, especially on the internet. The data subject should be able to exercise that right notwithstanding the fact that he or she is no longer a child.

Exceptions:

  • The further retention of the personal data should be lawful where it is necessary, for exercising the right of freedom of expression and information
  • for compliance with a legal obligation
  • for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller
  • on the grounds of public interest in the area of public health
  • for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes
  • or for the establishment, exercise or defense of legal claims.

And further:

  • the right to erasure should also be extended in such a way that a controller who has made the personal data public should be obliged to inform the controllers which are processing such personal data to erase any links to, or copies or replications of those personal data. In doing so, that controller should take reasonable steps, taking into account available technology and the means available to the controller, including technical measures, to inform the controllers which are processing the personal data of the data subject’s request.

Disclaimers

This post is based on my reading of GDPR and technical approaches that I feel will facilitate compliance as I understand it.

This is not intended to be a comprehensive discussion or instructions for complying with GDPR.

After taking all technical steps you feel are necessary to comply, you should consult an attorney to determine if the steps you have taken are sufficient for compliance.

For expert help bringing your database environment into compliance with GDPR, CCPA or other emerging privacy legislation, contact Buda Consulting.

 

 

Tracking Oracle Database Access for Regulatory Compliance

by | Apr 9, 2015 | Oracle DBA

Data stored in corporate databases is subject to increasing regulatory scrutiny. To ensure compliance with security guidelines in major regulations like SOX, PCI, HIPAA and FISMA, you need to implement controls not only to protect data from unauthorized access, but also to monitor and report on access when it occurs.

This capability, usually referred to as data access auditing, enables you to produce an audit trail regarding reads and writes to your Oracle database data. An audit trail can tell you after the fact what database objects were acted upon, who acted upon them, and when the action(s) occurred. Taken together, this data creates a state of non-repudiation, whereby a user cannot effectively deny that they performed the action in question.

Without this kind of comprehensive data, there’s no way you can effectively detect and deal with vulnerabilities or breaches related to your Oracle data, or pass a security audit (e.g., for ISO 27001 certification). You also can’t comply with regulations.

For example, the PCI Data Security Standard (PCI DSS) emphasizes the need to track access to cardholder data in real-time. PCI Requirement 10, in particular, requires companies to Track and monitor all access to network resources and cardholder data. Data access tracking is critical both for alerting and for analysis anytime there’s a concern. Without data access tracking there’s no hope.

HIPAA likewise mandates that Covered Entities and Business Associates be prepared to deliver an accounting of every time a patient record was viewed, let alone altered. Can you do that? If not, you might end up like the UCLA Health System, which paid a $865,500 fine for potential HIPAA violations after celebrity patients alleged that UCLAHS staff were looking at their protected health information (PHI) without permissible reason.

If you’re still not convinced, consider SOX Section 302.4.B – Establish verifiable controls to track data access. SOX mandates internal controls over all relevant data so that officers of public companies can’t plausibly deny that they are aware of, and in control of, changes.

So that’s the bad news: if you don’t have some kind of database auditing software in place for your Oracle data, you probably need it. The good news is that robust data auditing software, when properly configured and enabled for your environment, can reliably and comprehensively track the usage of your Oracle database resources. Then you can analyze and report on audit trail data anytime to respond to questions like, “When were Jane Smith’s payment account details last accessed?” or “Who changed Joe Jones’ appointment time?” Having a solid answer in a legal or regulatory context sure beats excuses…

But implementing database auditing can be tricky. Issues include what levels within the database to audit (database level, object level, user level), managing performance impacts, and storing the audit data efficiently and securely while keeping it accessible for reporting.

To provide database auditing for its customers, Oracle offers Oracle Audit Vault and Database Firewall, a unified solution that monitors database activity, provides the full spectrum of audit capabilities for compliance reporting and also detects and blocks unauthorized database activity like SQL injection attacks. There’s also Oracle Database Vault, which supports separation of duties and privileged user access controls. Oracle Database 12c (and older versions) also offer a range of security and compliance supports that complement database audit logs.

Do you have questions or concerns regarding your organization’s ability to track Oracle database access for compliance purposes? Contact Buda Consulting to discuss your environment and your needs.

Compliance 101 for Oracle DBAs

by | Nov 25, 2014 | Backup and Recovery, Best Practices, Oracle DBA

Regulatory compliance issues are top-of-mind for today’s senior executives. New laws and industry regulations are changing how organizations acquire, store, manage, retain and dispose of data. Every Oracle DBA should be aware of these changes because of their sweeping impacts on the DBA job role.

Compliance goes hand-in-hand with security because regulations often mandate that organizations be able to attest or even prove that data—and therefore databases—are secure and controlled. In this context, Oracle DBAs are directly involved in implementing and managing the policies and technologies that support compliance.

What are some of the key regulations that impact Oracle DBAs? Here in the US, one of the most prevalent is Sarbanes-Oxley (SOX), aka the U.S. Public Accounting Reform and Investor Protection Act of 2002. SOX is meant to reduce fraud and improve financial reporting. Its impact on IT is sweeping. In particular, it holds the CFO responsible to guarantee the processes used to produce financial reports, which invariably involve software accessing data stored in databases via processes maintained by DBAs.

For healthcare organizations the major regulatory worry is HIPAA, the Health Insurance Portability and Accountability Act. HIPAA mandates security measures for patients’ personal health information (PHI)—to the extent that an organization must be able to document every time a PHI data element was viewed. HIPAA audits often focus on the processes that drive exception logs and reports. Database auditing is critical in this regard.

Here are some typical Oracle DBA tasks that directly relate to compliance:

  • Data quality and metadata management. Ensuring data quality is key to regulatory compliance. If data or metadata aren’t accurate, how can the right data elements be subject to the appropriate regulatory controls?
  • Database auditing. As mentioned above, robust database audit capabilities can be essential for compliance with HIPAA and other regulations and policies that mandate tracking database usage. What data was accessed when and by whom? Database audit software can tell you. Database auditing is also vital for overall information security and detection of security breaches, especially against internal threats.
  • Data masking and obfuscation. Data masking practices are generally used to render original data suitable for testing purposes. It looks and functions consistently with the original data, but no longer constitutes personally identifiable information or credit card data, etc. for regulatory purposes. It’s also important for protecting sensitive data from staff (e.g., third-party contractors) working in non-production environments.
  • Database archiving and long-term data retention. Regulations often mandate what data must be stored for what period of time. This is also important for legal/eDiscovery purposes.
  • Database recovery. Database recovery is also a compliance issue, because it relates to database integrity and availability. If data is lost and can’t be recovered, that can be as problematic as a security breach from a regulatory perspective.

If you’re not sure whether your Oracle database policies, procedures and controls are adequate to support regulatory compliance, Buda Consulting can help. Contact us to discuss a database security assessment to identify areas of noncompliance and provide whatever assistance you need to address them.

 

Financial Services Spotlight: Risk Data Aggregation and Risk Reporting

by | Jul 17, 2014 | Best Practices, Oracle DBA

The finance, risk and compliance departments of any financial services firm all need fast and comprehensive access to business data in order to measure performance, manage risk and report to regulators and clients. But each department needs a specific view, whether strategic, operational or a combination of the two.

Risk data aggregation in particular has garnered considerable attention since the Basel Committee on Banking Supervision (BCBS) published Principles for effective risk data aggregation and risk reporting, often called BCBS 239, in 2013. Banks are required to be fully compliant with all eleven principles of BCBS 239 by January 1, 2016—and many will require considerable resources and expertise to get there.  

In the past, risk managers have often had to decide for themselves what data they needed. But regulators are now specifying more about what a risk management analytical framework needs to look like. The goal is to help financial services institutions individually and collectively to avoid counterparty risk and systemic risk, to help prevent a repeat of the 2008 financial crisis.

One of the key lessons learned in the aftermath of the 2008 crisis was that financial services organizations’ IT systems and data architectures were insufficient to enable the management of financial risks, especially around aggregating risk exposures and identifying concentrations of unacceptable risk quickly and accurately at the group level and across lines of business.

Data aggregation frameworks can offer a complete view of the risk inherent in each exposure, counterparty, customer, product and so on—in minutes rather than days. Having the right information at hand to make an optimal decision quickly can make an enormous difference. The delay in understanding what a bank’s total exposure to Lehman Brothers was at the peak of the crisis is a cautionary indication of the value of such a system.

But despite the clear mandate and clear benefits of developing compliant risk data aggregation and risk reporting, the Basel Committee’s December 2013 preparedness survey of thirty “systemically important banks” showed that these banks self-rated their compliance at 2.8 overall on a scale from 1 (noncompliant) to 4 (fully compliant). Principles 2, 3 and 6 (data architecture/IT governance, accuracy/integrity and “adaptability,” respectively) scored the lowest at around 2.5/2.6. Half the respondents indicated that they were far from being compliant in these areas. Since the principles are all interdependent, presumably some weak spots would make overall compliance a significant challenge.

To comply with BCBS 239 in time, financial services companies will need to:

  • Automate manual processes to accelerate data management and analytics
  • Consolidate today’s disparate views of risk
  • Bolster the reliability of risk systems and risk data quality assurance
  • Improve risk data governance, data ownership and procedural documentation

According to experts at Oracle, speeding up data management and analytics practices is key to avoiding the kind of risk that rocked the world in 2008. Firms that embrace near real-time/on-demand analytics and similar data management technologies will be able to aggregate data much faster across different classes, different lines of business and different data structures—including unstructured data. This will enable them to better pinpoint and evaluate risk to predict problems before they become catastrophic.

Of course, data quality is also vital. How can a firm calculate or predict risk exposure if its data is unreliable or incomplete?

Due to the complexity and diversity of many financial services firms’ data management systems, an objective, third-party assessment of where you are and where you need to go can be the best way to move “with all deliberate speed” towards compliance with BCBS 239.

Buda Consulting has over fifteen years’ experience with building and assessing these kinds of complex, mission-critical database applications. Get in touch to discuss how we can help you evaluate and address your risk data aggregation and reporting challenges.