Conducting PII Audits - Part 2 of 2

By: Mitchell H.Levine.CISA
Audit Serve, Inc.

The first part of the article which appeared in the June/July issue of Audit Vision discussed the various approaches for planning the PII audit.  As discussed in the first part of the article, the PII discovery and inventory organization initiative is comprised of either a self-assessment or centralized approach to identifying the location and securing PII data.

Even before assessing whether PII data is adequately controlled within an organization the audit must assess whether standards and policies have been established which define what is considered PII data based on legal and regulatory requirements and what is considered permissible use of PII data.   The permissible use of PII data in many cases should require controls established which require organization employees on an individual basis and within application system to declare their intent and justification for having PII data stored on individual PCs, file shares, or within application systems.  

The declaration of the use of PII data could occur prior to allowing a PC to be connected to the organization’s network and/or as part of the new hire process of setting up the individual’s network ID. .  Unfortunately, that would only capture new PCs or new employees.  This process could be supported by an annual validation process in which individuals and owners of application system declare whether they store PII data. Regardless of whether the declaration of the intended use of PII data is the basis for identifying the location of PII data, the use of automated tools to scan for the presence of PII data is a required control to ensure that PII data is stored in permissible locations.  It is understood that a centralized process for scanning network drives and application databases requires a tremendous amount of resources.  The question is whether the initiative of scanning for the presence of PII data is conducted once to perform a one-time cleanup or if an organization is willing to dedicate the necessary resources to perform the scanning on a periodic basis.  As part of the audit, the assessment of these scanning initiatives needs to be evaluated and tested to ensure that they covers all locations in which PII data can be present.  In addition, an assessment of the scanning tools needs to be performed to ensure the toolset covers all types of technology used (e.g., operating systems and databases).

The next phase of the discovery and security of PII data is to evaluate the organization approach used to determine whether access to the locations where PII data is stored is restricted to individuals based on the requirements of their job function.  Most organizations perform security access re-certifications on annual basis but in most cases it only includes access to the application functions and does not include the network file shares/directories that users have access to.  These re-certification processes used should be evaluated to determine whether it includes file shares and whether the review was also based on whether individuals were allowed to have access to PII data.  Obviously, if an effective PII inventory process is not in place, the recertification process would be useless to determine whether access to PII data was properly restricted.

A common approach within the industry for securing PII data is to set-up isolated locations to store all PII data which provides an easier administrative process for the inventory and securing of PII data.

The other part of the PII audit involves the assurance that PII data is properly secured when the organization needs to provide PII data to outside organizations.  The audit should focus on the organizational controls to ensure that the release of PII data outside the organization has been properly authorized.  In addition, the audit should validate the measures taken by an organization to ensure that these outside organizations are properly securing their data.  These measures could include survey audits, onsite vendor audits, or independent audits such as SSAE 16 reviews.  However, if SSAE 16 are used, it must be a SOC 2 review which includes the Confidential component of Trust Service Principal (TSP).  SSAE 16 SOC 1 audits do not cover confidentiality controls.  SOC 1 audits only include controls which impact the accuracy of financial statements, which is the update to data and not read access to data.

The last component of the PII audit include the assessment of the security awareness programs to ensure that all employees and contractors are properly trained in the handling and permissible use of PII data along with a review of the incident response plans to ensure that all security breaches are reported and managed properly. 

AuditNet - The Global Resource for Auditors

Audit Vision

Since 1991
Join 3,500 other subscribers



Free Audit Serve Seminars Posted Online

25 minute extract from the seminar entitled "Alternate Control Design Approaches for z/OS" presented by Mitch Levine in London (at the Churchill War Rooms) March, 2018 which would be of interest to IT Audit, Security and GRC personnel

General Data Protection Regulation Seminar

Copyright © 2015. All Rights Reserved.