ISACA Journal
Volume 1, 2,014 


Auditing for PII Security Compliance 

Derek Mohammed, Ph.D., CISA, CISM 

As business and individuals increasingly rely on information technology, more and more data that identify them exist across various information systems. Some elements of data are very personal and could be harmful if placed in the wrong hands. This type of information is known as personally identifiable information (PII). The US Government Accountability Office defines PII as “any information about an individual maintained by an agency, including (1) any information that can be used to distinguish or trace an individual’s identity, such as name, social security number, date and place of birth, mother’s maiden name, or biometric records; and (2) any other information that is linked or linkable to an individual, such as medical, educational, financial and employment information.”1

There are laws and regulations designed to protect PII in digital form. Examples of laws include the US Family Educational Rights and Privacy Act, the US Health Insurance Portability and Accountability Act (HIPAA),2 the Privacy Act in Australia, the Personal Information Protection and Electronic Documents Act (PIPEDA) in Canada, and the Data Protection Directive in the European Union.

Despite regulations for protecting PII, data leakage of PII is remarkably common. During the week of 11-17 April 2011, for example, Identity Finder posted nine reports of PII being stolen, lost or somehow exposed. Of these nine, one incident involved hacking into an international firm’s IT system to steal customer PII in order to extort that firm for money. Another incident involved the theft of PII by someone authorized to access the data. Yet another incident involved unauthorized access to credit card data due to a security flaw. The remaining six incidents were more typical. Three incidents involved the theft or loss of computer or data storage containing unencrypted PII, two incidents involved the accidental disclosure of PII to the public or a third party, and one incident involved an employee failing to destroy PII records before discarding them in the trash.3 Altogether, these nine incidents affected four million people and all were revealed during a single, typical week.

It is important to note that the vast majority of PII security breaches are preventable. Systems can be strengthened to prevent unauthorized access, and employee screening and training can be improved to prevent PII data leakage due to theft, loss or improper handling. However, very often it is not until after an incident has occurred that an organization makes a thorough review and necessary changes to practices regarding PII security. To reduce the number of PII data security breaches, organizations must embrace the concept of auditing for regulatory compliance and security for PII so that issues can be addressed preemptively.

Governance-level Audit

An audit for privacy security compliance must start at the top. An organization’s ability to establish a governance program that effectively addresses and manages IT risk is the key to successful PII security, as well as IT security in general. Without proper governance, controls for protecting PII may be uncoordinated, overlapping, gapped or absent. It is crucial that an organization’s senior management understand their PII risk factors and compliance requirements. To address this need, many organizations create an executive-level position, such as chief information security officer or chief compliance officer, that is responsible for identifying, assessing, tracking and addressing IT risk.4 If such a position exists, an auditor’s first stop should be a visit to this individual’s office to ask these broad questions:

  • Are PII compliance requirements identified and understood? An auditor must know that an organization has identified and understands the regulations that define and mandate security for PII. Different regulations have their own variations of how protected information is defined and treated. For example, HIPAA addresses security for protected health information (PHI), which it defines as any information that identifies an individual and relates that individual to past, present or future physical or mental health; the provision of health care; or past, present or future payments for health care.5 Therefore, the level of security that is needed to protect PII will vary and depend on the regulatory body that mandates protection.
  • What are the organization’s requirements for handling PII? After an organization has a clear picture of how PII is legally defined, it can examine where the protected information supports critical business processes. PII should only be captured, stored and maintained where absolutely necessary. Wherever possible, PII should be eliminated from business processes or de-identified. De-identifying PII means removing or obscuring enough attributes so that the information no longer identifies an individual.6 This enables an organization to continue to support a business function that relies on data derived from PII without having to incur the added risk associated with maintaining and processing PII within that function. The PII security compliance auditor should verify that the organization has properly applied the legal definition of PII in identifying its requirements for handling PII and verify that the organization has an established process for reviewing requirements and recommending elimination or de-identification of PII.
  • Has the organization conducted a risk assessment for PII? An organization should categorize its PII by the level of impact of a disclosure of information. Depending on the organization’s industry and the nature of PII, there are various factors that could be evaluated to determine the risk associated with each piece of PII. Potential factors include how identifiable the information is, the quantity of PII records, and the sensitivity of the data fields (for example, a social security number or a credit card number are more sensitive data than a person’s shopping habits or marital status).7 The auditor must verify that an accurate risk assessment has been conducted and that various PII pieces are being treated with the appropriate levels of confidentiality.
  • Are all necessary controls for communicating PII addressed in the organization’s security policy? The auditor must review the organization’s security policy to ensure that it addresses the required security measures for protecting PII in compliance with laws and/or regulations. The policy should clearly state goals that support adequate PII security and align with the organization’s compliancy requirements, business requirements and risk assessment, and from which effective standards, procedures and guidelines can be derived. The security policy should also call for monitoring compliance, enforcing sanctions against violators, and testing the effectiveness of controls through routine monitoring and security testing.

Procedural-level Audit

The next level the auditor should examine is the procedural level. This is the level in which strategic goals for PII security are translated into standards, procedures and guidelines. In addition, the definition of PII; the strategic goals; and the standards, procedures and guidelines are communicated to all employees at this level. The auditor must verify whether standards, procedures and guidelines align with and support policy goals for PII security, and that communication to employees is adequate and effective. The questions to ask at this level are:

  • Do standards, procedures and guidelines support the security policy goals? The auditor should review all standards, procedures and guidelines to ensure that they effectively support the goals of the organization’s security policy. This policy should address all PII security concerns, including, for example, proper access control, encryption, labeling and destruction. However, the scope of this review cannot be limited to standards, procedures and guidelines specific to PII, as any security measure affects the security of PII. For example, a lenient password reset procedure could allow unauthorized access to a workstation or database containing PII or a gap in physical security could allow someone to steal physical records or a device containing unencrypted PII.
  • Are all employees and/or users trained on how to identify and handle PII? Procedures should be in place to ensure that all employees are trained before they are exposed to PII. While there should be focused training for those directly dealing with PII, all employees across the organization should know how to identify PII and initiate the appropriate response to a PII security breach. The auditor must identify how policies, standards, procedures and guidelines are being communicated across an organization.8 The auditor must determine if the communication methods are effective and if there is sufficient accountability. For example, simply having a poster next to the coffee station describing PII and how to handle the information would likely be insufficient communication if the organization intends to enact sanctions against employees who violate handling procedures. What if an employee does not drink coffee? Formal training followed by a signed statement of understanding that is kept on file by human resources and that includes proper handling procedures and consequences for noncompliance would be much more appropriate in this scenario.
  • Are there effective plans and procedures for response to a PII security incident? Extensive preparation is often the determining factor when a security incident is not handled properly. The development of a PII security incident response plan forces relevant entities within an organization to make well-thought-out decisions on how to handle many details of a security incident. Decisions could include how to sanitize the situation, how to report the incident and how to compensate those affected. These decisions should be integrated into policies and procedures for response to a PII security incident.9 The auditor should verify that such plans have been developed and are continually reviewed to ensure that every imaginable scenario is considered.

Operational-level Audit

The final phase of the audit is where PII security compliance auditors conduct their own security testing and monitoring to assess the effectiveness of the controls. This is essentially testing to ensure that PII security is functioning properly. Organizations can have robust policies, procedures and training for protecting PII, but if employees at the lower level do not understand the training and/or are not following the procedures, or if unexpected security loopholes allow for unauthorized access, the organization’s investment in PII security will have been made in vain. A PII security audit is not complete without verifying that security measures are in place and effective in day-to-day operations. The questions to ask at this level are:

  • Is PII found out of bounds? Monitoring for PII should include data at rest and data in transit and should not be limited to business processes that use PII, but should span the entire organization to include the organization’s information systems (IS) perimeters. The auditor must verify that no PII can be found in business processes where it is not required and that encryption is effectively used when PII is in transit to at-risk areas, such as beyond the organization’s internal network, or is being stored in at-risk areas, such as on an employee laptop (prone to theft). The auditor must also scrutinize business processes that deal with PII to verify if more PII is being collected and stored than absolutely necessary.

    In monitoring data at rest, PII can reside in less-than-obvious places such as in metadata, deleted files or files marked for deletion, alternate data streams, graphical files, print spool files, link or shortcut files, RAM and page files, and the operating system registry hive. Additionally, there are many ways in which a nefarious user can obfuscate PII to prevent successful monitoring, such as by modifying file extensions. For these reasons, the best tools to monitor PII at rest during an audit are forensic tools.10

    After monitoring is complete, the auditor can determine the effectiveness of the organization’s internal monitoring process. The auditor should verify whether logging is enabled for all critical systems and whether the organization has adequately assigned the task of monitoring for execution. The auditor should also use monitor logs to verify if users are handling PII in accordance with procedures.11
  • Are access controls to PII being enforced? The auditor must verify whether access controls within an organization prevent unauthorized access to PII. Only authenticated users who are authorized may have access to PII. Only individuals who require access to support critical business processes should be authorized, and the auditor should verify that authorized individuals have undergone the required vetting. Testing should also include penetration testing to ensure that controls are effective and prevent unauthorized access from outside of the organization. The auditor should also verify that controls prevent privileged escalation attacks that enable unauthorized users from accessing PII, and that authorized user authentication meets adequate standards and guidelines to prevent an unauthorized user from gaining access to an authorized user’s account.
  • Is training effective? Are procedures being implemented and followed? There are a few ways that an auditor can verify whether employee training is effective. The auditor can simply interview employees and ask them to describe PII and follow the various security procedures with the employee. The auditor should review logs and verify whether employees’ activity matches their descriptions and that these match with the legal regulations and the organization’s security policy, standards, guidelines and procedures. Employees failing to follow procedures could mean that training is ineffective, or it could mean that sanctions are not harsh enough or are too laxly enforced, or it could be a combination of the two. If auditors identify failures to follow proper procedures, they must focus on identifying the cause of the breakdown in processes, rather than correcting each individual incident.


Conducting an audit for PII security compliance is a daunting and laborious task. It is not possible to limit PII auditing to specific sections or business processes of an organization and still have the audit remain effective. Likewise, it is not possible to limit the scope of a PII audit to a particular level and still judge the effectiveness of security controls. By using a three-level, top-down approach, auditors can efficiently cover an entire organization and avoid having to duplicate efforts or repeat processes due to deficiencies at higher levels.


1 US Government Accountability Office, “Privacy: Alternatives Exist for Enhancing Protection of Personally Identifiable Information,” Report 08-536, USA, May 2008,
2 Pan, Yin; Bill Stackpole; Luther Troell; “Computer Forensics Technologies for Personally Identifiable Information Detection and Audits,” ISACA Journal, vol. 2, 2010,
3 Identity Finder, Identity Theft News,
4 Rai, Sajay; Phillip Chukwuma; “Top 10 Security and Privacy Topics for IT Auditors,” ISACA Journal, vol. 2, 2010,
5 Yale University, HIPAA Policy 5100: Protected Health Information Security Compliance, 20 April 2011,
6 McCallister, Erica; Tim Grance; Karen Scarfone; Special Publication 800-122, Guide to Protecting the Confidentiality of Personally Identifiable Information, National Institute of Standards and Technology, April 2010,
7 Ibid.
8 Op cit, Rai
9 Op cit, McCallister
10 Op cit, Pan
11 Op cit, Rai

Derek Mohammed, Ph.D., CISA, CISM, is an assistant professor who teaches undergraduate and graduate courses in information security and assurance at a private liberal arts university in Texas, USA. Prior to joining academia, Mohammed worked extensively in both the public and private sectors to improve the security of critical information systems. His research focuses on IT auditing and security compliance.


Add Comments

Recent Comments

Opinions expressed in the ISACA Journal represent the views of the authors and advertisers. They may differ from policies and official statements of ISACA and from opinions endorsed by authors’ employers or the editors of the Journal. The ISACA Journal does not attest to the originality of authors’ content.