Playbooks
Application Goal:
Agile teams need access to high-quality test data to develop, test, and release new software, but that data often includes sensitive customer information that must be protected. The process of creating and managing test data must be designed with data privacy regulations in mind, including the General Data Protection Regulation (GDPR) and the Health Insurance Portability and Accountability Act (HIPAA). Organizations need to ensure that they have a comprehensive data privacy strategy that covers all aspects of their software development process, from test data creation to storage and disposal.
Accelario’s Agile TDM platform can help organizations address the challenge of maintaining data privacy compliance during the software development process. Our platform integrates data masking as part of the test data delivery workflows, ensuring that sensitive data is protected and compliant with data privacy regulations.
Application built-in data privacy regulations:
It is important to understand what each of the data privacy regulations covers, as it will allow to understand which of them is applicable to a specific project.
USA CCPA
USA PCI
USA HIPAA
GBR GDPR
A custom policy can be created to cover specific cases.
USA CCPA
The California Consumer Privacy Act of 2018 (CCPA) gives consumers more control over the personal information that businesses collect about them and the CCPA regulations provide guidance on how to implement the law.
What is considered personal information and sensitive personal information under the CCPA?
Personal information is information that identifies, relates to, or could reasonably be linked with you or your household. For example, it could include your name, social security number, email address, records of products purchased, internet browsing history, geolocation data, fingerprints, and inferences from other personal information that could create a profile about your preferences and characteristics.
Sensitive personal information is a specific subset of personal information that includes certain government identifiers (such as social security numbers); an account log-in, financial account, debit card, or credit card number with any required security code, password, or credentials allowing access to an account; precise geolocation; contents of mail, email, and text messages; genetic data; biometric information processed to identify a consumer; information concerning a consumer’s health, sex life, or sexual orientation; or information about racial or ethnic origin, religious or philosophical beliefs, or union membership. Consumers have the right to also limit a business’s use and disclosure of their sensitive personal information.
USA PCI
The PCI DSS applies to any organization (regardless of size or number of transactions) that accepts, stores, transmits, or processes cardholder data.
Cardholder data refers to any information printed, processed, transmitted or stored in any form on a payment card.
If you are a merchant, the PCI DSS applies to you. Even if you have subcontracted all PCI DSS activities to a third party, you are still responsible for ensuring all contracted parties comply with the Standard.
If you are a service provider, including a software developer, the PCI DSS applies to you if you process, transmit or store cardholder data, or your activities affect the security of the cardholder data as it is being processed, transmitted, or stored.
USA HIPAA
The Standards for Privacy of Individually Identifiable Health Information ("Privacy Rule") establishes, for the first time, a set of national standards for the protection of certain health information. The U.S. Department of Health and Human Services ("HHS") issued the Privacy Rule to implement the requirement of the Health Insurance Portability and Accountability Act of 1996 ("HIPAA").1 The Privacy Rule standards address the use and disclosure of individuals' health information—called "protected health information" by organizations subject to the Privacy Rule — called "covered entities," as well as standards for individuals' privacy rights to understand and control how their health information is used.
Protected Health Information.
The Privacy Rule protects all "individually identifiable health information" held or transmitted by a covered entity or its business associate, in any form or media, whether electronic, paper, or oral. The Privacy Rule calls this information "protected health information (PHI)."12
"Individually identifiable health information" is information, including demographic data, that relates to:
the individual's past, present or future physical or mental health or condition,
the provision of health care to the individual, or
the past, present, or future payment for the provision of health care to the individual,
and that identifies the individual or for which there is a reasonable basis to believe it can be used to identify the individual.13 Individually identifiable health information includes many common identifiers (e.g., name, address, birth date, Social Security Number).
GBR GDPR
The General Data Protection Regulation is a European Union regulation on Information privacy in the European Union and the European Economic Area.
The regulation applies if the data controller (an organisation that collects information about living people, whether they are in the EU or not), or processor (an organisation that processes data on behalf of a data controller like cloud service providers), or the data subject (person) is based in the EU. Under certain circumstances,[3] the regulation also applies to organisations based outside the EU if they collect or process personal data of individuals located inside the EU. The regulation does not apply to the processing of data by a person for a "purely personal or household activity and thus with no connection to a professional or commercial activity." (Recital 18)
According to the European Commission, "Personal data is information that relates to an identified or identifiable individual. If you cannot directly identify an individual from that information, then you need to consider whether the individual is still identifiable. You should take into account the information you are processing together with all the means reasonably likely to be used by either you or any other person to identify that individual."[4] The precise definitions of terms such as "personal data", "processing", "data subject", "controller", and "processor" are stated in Article 4 of the Regulation.[5]
After you understand which of the policies you need to apply there are 4 general steps to implement:
Scan the database
During this stage, the database will be scanned with applied policy in order to identify tables with sensitive information
It will also create a report of table/column which contain sensitive data.
Investigate the report.
During this stage, you will be looking at the reported tables/columns with sensitive data,
it will also contain an indication of probability that the data in particular column is sensitive.
You should look through the report and make sure that the result is a satisfactory, it is also a common practice to share the report with data analysts and ask them to identify if the findings a accurate.
If you found a column which was not reported as a sensitive data, but you believe it should be masked, you may manually add the column to be masked.
It is also possible to add a custom rule to find sensitive data if built-in rule do not have such one.
When you look at the report, it is advised to look for “comments/notes/etc.” like columns are identified as a sensitive data,
Many times the column has NULL, hence the scan can miss it, but it is advised to look into database and see if such columns don’t have any sensitive data like emails, names, IDs etc as those may be part of a long text.
If you know a column name which have a “comments/notes/etc.” you may create a custom rule based on column name and mask it to NULL or some dummy data as those columns are not affecting application logics.
Masking
During the step, the application will perform an actual masking job.
You may see the progress of the job in UI, REST API.
You may also observe database load through available database tools, EM, sql queries etc.
Review the job results.
At this step, look into job monitor to make sure the process did not have errors.
If you spot any table which had errors during masking, you will need to investigate the root cause of the error.
For more detailed information about the product please refer to Users' Guide