Right to Access
PII data is rarely in one searchable location. It’s spread throughout the organization at the main office, remote offices, branch offices, home offices, the cloud, even laptops. Identifying all of it and making it available on demand to consumers who request it, in a timely manner (typically less than 30 days), is unlikely to happen.
The minimum low level EU General Data Protection Regulation (GDPR) fine is €10,000,000 or 2% of worldwide revenues, whichever is more. The next level fine is twice that. PDPA fines start at S$1,000,000. These are fines with teeth.
There are two “Right to Access” problems that needed to be solved to be compliant:
The first is to minimize the number of repositories requiring search
The second is to be able to search both structured and unstructured data
There is a misguided belief that PII data is only in databases. Most IT pros know that’s not true. Sales people alone frequently transfer CRM data to spreadsheets to simplify their ability to do their job. PII data exist quite a bit in unstructured data.
Right to Erasure
“Right to Erasure”, a.k.a. “Right to be Forgotten”, is the most difficult and most violated PII of the compliance requirements. The regulations specifically call out for organizations to erase PII data upon request, or when the purpose of collecting that data has expired, or the PII data has aged out.
What does this involve?
Of course, the PII data has to be found first. Once the PII data is located it must be erased and documented what was erased, when it was erased, how it was erased, and who erased it. Structured data, a.k.a. database application data, is relatively easy to search, erase, and document the PII data erasures.
There are two areas where Right to Erasure are extremely difficult to manage and be compliant:
The first is within unstructured data
The second is within backups, especially the very popular image-based backup a.k.a. snapshots. Non-compliance is potentially quite expensive
As discussed in the Right to Access section, finding PII data in unstructured data requires both the metadata and data be indexed.
The second problem of finding and erasing PII data from backups is much more troublesome and likely to put the organization in non-compliance.
But then, the PII erasures cannot corrupt any of the other backups. This is a problem for the very popular image-based backups.
Image backups are linked enabling each backup after the first to be block changes only. Mounts or recoveries create a virtual copy that pieces the backups together to what the data looked like at that point-in-time.
Deleting data from a given image backup is very problematic. Every stored backup taken before the PII data was erased, but after the backup in which the PII data was erased, will have pointers to the PII data that no longer exists.
This causes the subsequent stored backups to be corrupted. And every changed block backup after the corrupted ones will also be corrupted. File backups frequently also have this problem.
How Can ioFABRIC Help?
Backups are the central repositories for applications, servers, virtual machines, cloud computing, and laptops.
ioFABRIC converts those backups into open standard backup format enabling the data to be both mountable and recoverable without the backup software.
- For structured or database PII data, it mounts and makes the database data available to the databases that created them. This enables a quick SQL or NoSQL search of those databases for the required PII data.
- For the unstructured data, it scans and indexes both the metadata and the data.
This simple to use process makes it quite easy to search for and find PII data in the unstructured data via the ioFABRIC software ensuring “Right-to-Access” PII compliance.
Learn more about how ioFABRIC can help, or read the solution brief.