Personally Identifiable Information Job Aid

Software Development Lifecycle (SDLC) Job Aid: Personally Identifiable Information Business Unit Project Standards & Governance Revision Information Ver. 1.2 – January 2012 Filename: Job_Aid-PII_Jan2012_v1.2.docx Abstract The purpose of this document is to provide the context to the requirement to protect Personally Identifiable Information (PII) in test systems and to provide application teams with options to achieve compliance. Audience This document is intended for anyone involved with or running a project for an application that contains PII. Template Revision—October 2011 IMPORTANT NOTICE This document and the information contained herein are the property of Northern Trust Corporation and are intended for the internal use of employees, agents and representatives of Northern Trust Corporation. Any unauthorized use of, reproduction of, or reference to the information included in this policy, whether direct or implied, is prohibited. CONFIDENTIAL—FOR INTERNAL USE ONLY

Software Development Lifecycle (SDLC) Job Aid: Personally Identifiable Information Table of Contents 1. Introduction ...................................................................................................................... 3 2. The definition of Personally Identifiable Information (PII) .............................................. 3 3. The Application Inventory (Software Asset Management) ............................................... 4 4. Options for handling PII ................................................................................................... 4 4.1 Remove all production data copies .................................................................................... 4 4.2 Mask the PII data ............................................................................................................ 5 4.3 Tighten access controls .................................................................................................... 5 5. Where can I get more information ? ................................................................................. 6 6. Document Control ............................................................................................................. 6 6.1 Revision History .............................................................................................................. 6 6.2 Signoff Tracking Chart ..................................................................................................... 6 6.3 Reference Documents ...................................................................................................... 7 6.4 Glossary: Definitions, Acronyms, Abbreviations ................................................................... 7 Job_Aid_PII_Letter Ver. 1.2 – January 2012 Page 2 of 8

Software Development Lifecycle (SDLC) Job Aid: Personally Identifiable Information 1. Introduction 1 In October 2010 following regulatory and audit pressure , but also in line with Northern Trust’s policy 2 on protecting confidential information , Technology Risk Management updated the corporate Software 3 Development, Acquisition and Maintenance standard (SDAM) to make the sanitization of Personally 4 Identifiable Information (PII) mandatory for all projects and applications . The wording of the mandatory requirement is: “When using a copy of production data for testing purposes, this data should be sanitized by masking any data fields that could be construed as PII....” The revised SDAM was published in August 2011. It became effective immediately for new projects st and applications with a grace period for production or in-flight applications until 31 March 2012. Going forward all applications teams should expect to have a review of PII within the scope of their internal and external audits. The purpose of this document is therefore to provide guidance on the options available to application support and project teams to meet the PII requirement. 2. The definition of Personally Identifiable Information (PII) The Corporate Guidelines for Protecting Confidential and/or Proprietary Information, explicitly states that PII is a subset of confidential information as follows: ‘Personally Identifiable Information or “PII” (sometimes referred to as “sensitive confidential information”) – is a subset of Confidential and/or Proprietary information.’ By definition therefore, PII does not include all confidential information. The guidelines continue to focus on PII as relating to people: PII is… ‘information relating specifically to a past, present or prospective Northern Trust personal client or information relating to a contact or client of our corporate clients’ Additionally, the examples provided, such as tax identification code, suggest that it is indeed personal information that is in question, i.e. information directly relating to human individuals. However the use of the word “client” above introduces an ambiguity that is not helpful, as it can relate to a person or corporate entity. Risk and Compliance has also stated in writing “Data Protection relates to data (PII) which can be used to identify an individual, not a legal entity. A client can, of course, be either.” In addition in Q4 2011, PII was defined as follows in the corporate e-mail standard \"Personally Identifiable Information is information which can reasonably be used to determine the identity of any individual, or to permit access to or to create a new personal account, specifically: Person’s Name, address, or telephone number, in combination with Social Security number, Social Insurance number or any other tax identification number drivers license number, account number, credit card number or debit card number, or a personal identification number or password that would permit access to the customer’s account.\" 1 The reason for the pressure is directly related to PII data potentially being used fraudulently, e.g. for identity theft. 2 Corporate Guidelines for Protecting Confidential and/or proprietary Information 3 Corporate Software Development, Acquisition and Maintenance standard 4 This was previously a guideline/best practice, and not a mandatory requirement. Job_Aid_PII_Letter Ver. 1.2 – January 2012 Page 3 of 8

Software Development Lifecycle (SDLC) Job Aid: Personally Identifiable Information As a result, PII has been tightly defined as information relating to human individuals only. Such data is in scope, as they represent the most obvious risk for potential identity theft. All other data is out of scope. 3. The Application Inventory (Software Asset Management) 5 All applications should of course be catalogued in the Application Inventory as required by the Software Development Lifecycle (SDLC). Each application in the Inventory has a binary Yes/No field to specify whether it contains PII data or not as shown in the screenshot below. 6 This field however does not tell you whether:  the PII data is internal (e.g. about employees), or external (e.g. about contacts at a client)  the PII data is imaged only  the application that has the PII data is externally hosted 7  whether data is copied from production to test or development environments 8 All of which may be factors to determine if an application is in scope for PII controls . In 2011 internal PII, external PII related to vendors/suppliers, imaged PII and externally hosted systems were considered out of scope. It is likely this will change in the future. An application team that is in doubt should either simply decide to address PII data in test, which is the safest option, or should contact Technology Risk Management for an assessment. 4. Options for handling PII Each project/application team that needs to deal with PII data has to decide which of the following options to take. 4.1 Remove all production data copies The safest and cleanest option is for all data copied to test from production to be deleted. This leaves no doubt that live PII data is only available in the production system and is therefore protected correctly. Of course, deleting production data copies means that testing in all test environments has to be performed with artificial, fabricated data. While this is feasible, it does raise questions regarding how 5 The Application Inventory on Sharepoint has been decommissioned and is now available under Software Asset Management on Service-Now 6 This screenshot is from the original Sharepoint system, however equivalent attributes are available on Service Now 7 If an application has PII but production data is never copied to test then the application is out of scope. 8 At the time of writing (Q3 2011) in-scope PII applications where test environments need to be addressed are restricted to those that contain external client PII data, where the PII data is not imaged, where the application is not externally hosted and where data is copied from production to test. Job_Aid_PII_Letter Ver. 1.2 – January 2012 Page 4 of 8

Software Development Lifecycle (SDLC) Job Aid: Personally Identifiable Information easy it is to test effectively with such data. Each team must decide themselves (and in conjunction with their business unit partners for UAT) whether this is viable. 4.2 Mask the PII data At the time of writing, the scope of PII data has been defined to be 4 fields at minimum.  Name  Address  Tax identification  Date of birth These fields should be masked in test environments if the data has been copied from production. Other fields which you reasonably conclude are personal information should also be protected via masking as well. It is expected that as part of the process of copying data from production to test, one of the following will be performed: 1. Replace the field contents with blanks or some other constant value. 2. Define a logical masking algorithm and then physically mask the content of the fields using this algorithm. 3. Scramble the PII data by sorting it and allocating the fields to different records in the test database. 4. Formally encrypt the content of the fields using generally accepted encryption methods. The actual process for encrypting/masking needs to be determined by the application team, although it is expected one of two methods will be used:  Local manual scripting to update the fields at the point where they are populated in the test environment. 9  Use of the Cognizant D-Cipher automated tool . It should also be noted that PII data transported on interface files between applications is in scope and needs to be masked. Each application team needs to confirm with the suppliers of data to their system, exactly what will be provided for PII. Similarly each application team should publish to other teams that consume their data downstream what they can expect. In some circumstances this may require agreement between different application teams on the method of masking to be used. 4.3 Tighten access controls 4.3.1 User Acceptance Testing The SDAM is quite clear that the only approach is to sanitize/mask the PII data. However it is recognized that User Acceptance testing (UAT) environments are intended for business use. The expectation is that when testing, business users will need to access data that is similar or equivalent to what is seen in production systems. Sanitization of such data, while an option, would not be acceptable, because it will introduce a risk that effective UAT and sign-off will be compromised. So, to allow business users to continue to test in the manner they expect, a further option is available which is that access to UAT systems containing PII will need to be tightened. This means that controls relating to the granting of access (requests, approvals) and on-going management review that existing access is appropriate, are equivalent to production system access controls If an application team determines tightening access controls is their preferred option for UAT, a 10 deviation from standard will be required . 9 Implementing use of the tool is the responsibility of the application team. Other tools may be viable, however assessment, funding and commissioning of them is also the responsibility of the application team. Job_Aid_PII_Letter Ver. 1.2 – January 2012 Page 5 of 8

Software Development Lifecycle (SDLC) Job Aid: Personally Identifiable Information From a practical perspective, taking this option means:  Interaction with the Identity Manager (IdM) team to add the UAT environment to IdM so that access requests/approvals and reviews of access can be performed in exactly the same way as with production  The removal of generic ids from UAT (or at minimum linking the generic id to a specific LANid that has been approved through IdM and logging each use of the generic id/LANid combination) 4.3.2 Other test environments The expectation is that test environments used solely by Technology (development/unit test, system test, and perhaps integration test), will have PII data sanitized when copied from production systems. However it is recognized that in some circumstances this may not be desirable. In such cases, tightening access controls as described for UAT environments will need to be applied in the same fashion to each test region where production PII data may reside. Again, from a practical perspective, taking this option means:  Interaction with the Identity Manager (IdM) team to add each test environment to IdM so that access requests/approvals and reviews of access can be performed in exactly the same way as with production  The removal of generic ids from each test environment in scope (or at minimum linking the generic id to a specific LANid that has been approved through IdM and logging each use of the generic id/LANid combination) As with UAT, if an application team determines tightening access controls is their preferred option for other test environments, a deviation from standard will be required. 5. Where can I get more information ? At the time of writing there is a PII SharePoint site that may provide an answer to questions you have. It is expected however that this site will be decommissioned in 2012. Otherwise, if you still have questions please contact Technology Risk Management (TRM). 6. Document Control 6.1 Revision History Version # Revision Date Description 1.1 2011-Oct-01 First published version 1.2 2012-Jan-17 Fixed hyperlinks, added revised PII definition, fixed typos 6.2 Signoff Tracking Chart Partner Name Responsibility Version Approved Approval Method PSG PSG 1.2 10 Because this approach is not currently specified in the SDAM standard dated October 2010 Job_Aid_PII_Letter Ver. 1.2 – January 2012 Page 6 of 8

Software Development Lifecycle (SDLC) Job Aid: Personally Identifiable Information 6.3 Reference Documents Document Name Version Summary Link Corporate Guidelines for March See document name, however also on the Protecting Confidential 2010 contains the definition of PII. Northern and/or proprietary Trust Information intranet Corporate Information Asset April See document name. on the Security Policy and 2010 Northern Handbook Trust intranet Corporate Software October This is the standard updated so that it is on the Development, Acquisition 2010 mandatory for PII data to be masked in Northern and Maintenance standard non-production environments, with target Trust st date of 31 March 2012 intranet Information Asset Work in Process definition for information/data on the Classification progress classification. There is an associated Northern standard that is currently in draft status. Trust intranet Software Development Q1 2010 Project Lifecycle definition on the Lifecycle Northern Trust intranet 6.4 Glossary: Definitions, Acronyms, Abbreviations Term Definition Anonymized Data Data that has been replaced by one or more code words, e.g. “Dynamo” or specific text e.g. “afWd” for a client whose real name is “National Electricity Grid”. This is not equivalent to data masking but is acceptable as a method to sanitize PII. Data masking See sanitization PII Personally Identifiable Information. Defined in the Northern Trust Corporation Guidelines for Protecting Confidential and/or proprietary Information published in March 2010, as follows \"Personally Identifiable Information or “PII” (sometimes referred to as “sensitive confidential information”) – is a subset of Confidential and/or Proprietary information. It is information relating specifically to a past, present or prospective Northern Trust personal client or information relating to a contact or client of our corporate clients; examples include, but are not limited to:  A client's name, address, Tax Identification Number, date of birth, transaction account numbers, credit/debit card numbers, online banking user names, or passwords;  Information about a client’s accounts or borrowings;  Information about a client’s current or proposed transactions.” For this initiative, a tighter definition is being used, see section 2.1 Sanitization In this context, the process of overwriting (deleting) sensitive information and replacing it with fabricated data – possibly via an encryption method - so that the original is kept secure and is not traceable. Job_Aid_PII_Letter Ver. 1.2 – January 2012 Page 7 of 8

Software Development Lifecycle (SDLC) Job Aid: Personally Identifiable Information Term Definition SDLC Software Development Lifecycle UAT User Acceptance Testing. Testing undertaken by business users to ensure an application operates as intended and expected prior to it being commissioned in production. Job_Aid_PII_Letter Ver. 1.2 – January 2012 Page 8 of 8