Data Handling and Privacy Process
This document is describes a process for the GSOC to enable the secure collection, processing, communication, storage and disposal of data in compliance with the Global Data Protection Policy, the Inter-Firm Data Protection Agreement, Global Information Classification Policy and applicable local/regional Data Protection and Privacy regulatory requirements, in the performance of its services.
This process covers data that is stored, collected or processed by the GSOC as well as any data used in the configuration of systems used by the GSOC. The document does not go into elaborate detail, provide low-level technical procedures, or address all potential outcomes or failure cases in relation to handling of data within the GSOC. All GSOC personnel are expected to keep updated with the periodic updates to privacy and data protection regulation as well as exercise their best judgment when handling data especially when it contains Personal Identifiable Information (PII).
This document is owned by the GSOC Director. He or she is responsible for ensuring that this is updated and maintained in response to feedback from the GSOC Privacy Liaison Officer.
This document is intended for all GSOC members (see Section 2.9 – Responsibilities).
Exceptions to this process can be temporarily authorized by GSOC Privacy Liaison. Documentation of any process exceptions must be provided to GSOC management for potential process modifications as well as submitted to and signed off by the IRSO.
Failure to adhere to this process must be reported to the GSOC Director.
The following roles have overall responsibility for elements of this process. Please note that these are not comprehensive listing of responsibilities of each of the following roles, but represent these roles’ specific responsibilities to support the Data Protection and Privacy process.
The Information Risk and Security Office (IRSO ) is responsible for ensuring that all information risk and security concerns are managed effectively within defined risk levels (based on the firms risk appetite).
The IRSO maintains records of (amongst other records) all privacy requirements and provide approvals/signoffs for all Privacy Change Notifications/Request before rollout.
Each member firm has a National IRSO that liaises with the Global IRSO on issues of risks associated with data that the GSOC handles.
The GSOC Privacy Liaison Officer (GSOC PLO) is responsible for ensuring that the GSOC complies with the Global Data Protection Policy (which can be found here), the Inter-Firm Data Protection Agreement and with any local Privacy legal and regulatory requirements to which GSOC is subject.
He/she is responsible for driving the Privacy Change Notification process thus ensuring that the “Inter-Firm Agreement (IFA) Schedule A Questionnaire is completed and submitted to the IRSO for changes to the GSOC applications or processes.
The GSOC PLO works with the IRSO, Member Firm Privacy Liaison (MFPL) and other stakeholders to ensure continuous alignment of GSOC privacy practices and controls to address regulatory privacy changes that may affect the GSOC (especially from local law in the countries in which the GSOC holds and processes personal data).
The Member Firm Privacy Liaison (MFPL) is the Single Point of Contact on Privacy-related matters concerning the Member Firm and is accountable for assessing, accepting and documenting Privacy compliance of personal data sent to or accessed by the GSOC with KPMG Privacy-related policies, processes and controls, and with local legal requirements.
Each MF PL is responsible for carrying out in-firm Privacy Impact Assessment to evaluate whether transfers of personal data is compliant with local privacy laws and regulations. On an ongoing basis, the MF PL will also be responsible for carrying out Privacy Impact Assessments to assess and document the risks and impact of implementing a proposed change on receiving a Process Change Notification (PCN) from stakeholders (including Asset Owners, GSOC PL etc.).
1.7.4 Asset Owner
The Asset Owner of all GSOC assets is the GSOC Operations Manager. The responsibilities listed below are assigned to the role of Asset Owner:
- Be accountable for compliance of personal data processing performed by the owned asset.
- Liaise with – and seek advice from – the Member Firm Privacy Liaison on Privacy-related matters.
- Work with the Member Firm Privacy Liaison to assess the impact of changes documented in a Processing Change Notification.
- Submit requirements and questions in relation to a PCN to the Member Firm Privacy Liaison.
1.7.5 GSOC Director
The GSOC Director is responsible for ensuring that all members of the GSOC adhere to privacy requirements and that all activities performed by the GSOC are compliance with relevant KPMG policies and national laws.
The GSOC Tooling Engineer will ensure that systems within the GSOC are configured to support GSOC operations within the boundaries of this process.
The GSOC Reporting Analyst is responsible for ensuring that reports sent out of GSOC complies with all applicable policies and processes.
All GSOC Members are to know their responsibilities in data handling.
- System (Architecture and/or Configuration) Changes
- GSOC Change Management Process
- GSOC Change Management Process
- GSOC Content Management Process
- Triage Process
- Intelligence Management Process
Please refer to the KPMG International Data Classification Policy for definitions of the classification levels (link). The table below lists the classification of data within GSOC.
|Logs from MFs||KPMG Highly Confidential|
|Reports and metrics created from MF logs||KPMG Highly Confidential|
|Public Threat Intelligence||KPMG Highly Confidential|
|Open Source Threat Intelligence||KPMG Highly Confidential|
|Closed Source / MF / Paid / Vendor Threat Intelligence||KPMG Highly Confidential|
|Custom Threat Intelligence created from Public/Open Source/Closed Source/Paid/Vendor Threat Intelligence||KPMG Highly Confidential|
For information sharing, the following classifications shall be used. The classification is adopted from the Information Sharing Traffic Light Protocol (ISTLP) in use by Computer Emergency Response Team (CERT) globally. A description of the ISTLP is in Appendix 2. If data is shared with members outside of the permitted group (e.g. sharing Red data with members not involved in the initial exchange), data handling procedures in Section 3.5 shall apply.
|Reports and metrics created from MF logs||Red|
|Public Threat Intelligence||Green|
|Open Source Threat Intelligence||Green|
|Closed Source / MF / Paid / Vendor Threat Intelligence||Red|
|Custom Threat Intelligence created from Public/Open Source/Closed Source/Paid/Vendor Threat Intelligence||Red|
All data received by the GSOC shall be categorised to the tables in Section 3.1 and the data classification shall apply upon receipt.
It is key to note that the GSOC contains a mix of data, and depending on the data, GSOC can either be a data controller or data processor. The below table lists the data and GSOC’s role in Data Privacy. This section only applies to PII or data potentially containing PII.
|Logs from MFs||Data Processor|
|Reports and metrics created from MF logs||Data Controller|
|Public Threat Intelligence||None|
|Open Source Threat Intelligence||None|
|Closed Source / Paid / Vendor Threat Intelligence||Data Processor|
|Custom Threat Intelligence created from Public/Open Source/Closed Source/Paid/Vendor Threat Intelligence||Data Controller|
2.3 Personal Identifiable Information Lifecycle
GSOC personnel and stakeholders shall be governed by the following procedures when handling and processing PII.
Data is collected from event sources from a subscribing firm via a series of collection and aggregation systems before they are warehoused and processed further by the Secure Analytics system. The data collected from the various firms for analysis/further processing would potentially contain PII that may be subject to certain local regulations from the originating or processing jurisdictions. Agreement for management and usage of such data will be covered within the Inter-Firm Agreement (IFA).
Data Protection will be covered in Section 3.6.
The goal of the data processing phase is to analyse data and threat intelligence received and decided subsequent steps in an effective, efficient and timely manner.
However, given that the data being analysed during the Triage process and well as the Threat Intelligence process are not all sourced from same location (i.e. subject to same privacy regulations), there is need for the various analysts to exercise due care in the handling of such data and also the extent to which they may be able to drill further in their analysis as certain restrictions or defined measures may be required of them. MF PL’s are responsible for advising the GSOC if there are any particular requirements that need to be met due to local law or regulations.
The purpose for processing shall be agreed in accordance with the Inter-Firm Agreement (IFA). Additional actions and updates to this document might be required if agreement to process is not reached.
Please refer to Section 3.1 for their data / ISTLP classification and Section 3.5 and Section 3.6 for appropriate actions to take.
The reports will be tailor made to suit specific defined target audiences. Thus templates will be designed by the GSOC Reporting Analyst in liaison with the GSOC PL to ensure reports are in compliance with applicable policies and regulations.
For ad-hoc or new reports outside the predefined reports, the GSOC Reporting Analyst will review the request and (in working with the GSOC PL) ensure that there are privacy concerns are handled appropriately.
Where GSOC is a data controller, data will be retained for a minimum of 2 years. Where GSOC is a data processor, reasonable effort will be taken to retain the data for 180 days. Please refer to Section 0 for breakdown of GSOC’s role in data privacy.
KPMG International relies on each local firm to define their data disposal methods. Please refer to this link for disposal of physical media and documents. However, KPMG UK LLP does not have any electronic data disposal methods and the below will be used for GSOC.
For all data stored on encrypted devices where the encryption key is securely protected, a normal delete and emptying of ‘Recycle Bin’ (or similar for non-Windows devices) is sufficient.
For all data stored on non-encrypted devices, please refer to NIST 800-88 for the appropriate method for the media type. Additional guidance as follow:
- For data on devices which will remain physically secured within GSOC’s premises and not repurposed (e.g. Databases, excel spreadsheets), a normal deletion will be sufficient.
- For data on devices which will remain physically secured within GSOC’s premises and repurposed (e.g. hard disk moved from Server A to Server B), clearing the data would be sufficient.
- For data on devices which will leave GSOC’s premises, regardless of purpose shall be purged or destroyed.
2.4 Privacy Interfaces between GSOC and other Stakeholders
This section defines when and how GSOC will communicate with external stakeholders with regards to privacy. Each section below will detail scenarios where privacy might be impacted. This process document shall be updated when new scenarios have been identified.
2.4.1 Change Management
Changes to GSOC are expected as a result of, but not limited to, capacity management, continual improvement or incident management. In the process of change, the way data is stored, processed, retained and/or disposed of might change. Within every change request, the impact to privacy shall be assessed by the GSOC PLO and each MF PL.
Please refer to Change Management Process on how the GSOC PLO, and MF PL will be contacted.
In this scenario, GSOC will be responsible for contacting the GSOC PLO.
Schedule A captures all details of privacy data within GSOC. At any point where Schedule A is to be changed, the Data Privacy Liaison Officer must be contacted.
In this scenario, GSOC will be responsible for contacting the GSOC PLO.
As a Business As Usual activity, the GSOC will be monitoring for incidents happening across all MFs that have signed up for the GSOC service. As such, it is important to distinguish between security incidents targeting GSOC, and security incidents detected from monitoring Member Firm logs.
22.214.171.124 Security Incidents targeting GSOC
This scenario is only applicable where the GSOC is the victim of an attack. KPMG International relies on local firms’ data breach processes. As such, GSOC shall apply KPMG UK LLP’s data breach processes as described here. In additional, the GSOC PLO must be notified. In this scenario, GSOC will be responsible for contacting the GSOC PLO.
126.96.36.199 Security Incidents from Monitoring MF Logs
The Security Incident Management Process will provide additional detail. As requested by the PLO, the GSOC PLO shall be notified for P1 and P2 incidents until the system has stabilised and further tweaking might be required.
Laws change over time and there might be changes which would impact the way GSOC is allowed to operate. In such a scenario, the GSOC PLO shall contact the GSOC Director (or his delegate) for further action.
2.5 Data Handling for Data Leaving GSOC
This section focus on data exiting GSOC. Data handling within GSOC is covered in Section 3.6.
If data is sent to parties outside of the allowed parties (e.g. sharing Red data with members not involved in the initial exchange), they must be sanitised to the level of Green before they can be sent out. Please refer to Appendix 1 for sanitisation procedures.
All PII data leaving GSOC must be subjected to data sanitisation and/or redaction to remove all PII as described in Appendix 1.
The following table describes how data shall be protected. The structure of the table is extracted from the KPMG International’s Information Classification Policy User Guide.
|Accessing||Permanent Storage||Temporary Storage or Transfer||E-Mailing||End user Back Up||Disposal|
|KPMG Public||No restrictions||No restrictions||No restrictions||No restrictions||No restrictions||Delete files when no longer required|
|KPMG Confidential||Business need to know||In approved central repository or on encrypted KPMG laptop||Approved encrypted KPMG removable media (e.g. USB device)||Approved KPMG e-mail only. Encryption of attachments recommended e.g. WinZip||Use only KPMG approved encrypted external storage device||Secure disposal using approved local processes|
|KPMG Highly Confidential||Please refer to Security Requirements (LAM/RSA Archer) for details. This is a document created by the GSOC project and can be found in the project’s archives.|
The recommended ways to sanitise or redact information are as follow:
- Hardcopy – Please refer to Appendix 1 of National Archives Redaction Toolkit
- PDF – Please refer to this link – Redaction of PDF Files
- Plain text files – Deletion of text is sufficient
- Any other format – It is difficult to provide any assurance for irrecoverable sanitisation for any other formats besides those described above. If any document format besides the above needs to be sanitised, the written approval of the GSOC Operations Manager needs to be sought prior to release.
|Red||Non-disclosable information and restricted to representatives participating in the information exchange themselves only. Representatives must not disseminate the information outside the exchange. RED information may be discussed during an exchange, where all representatives participating have signed up to these rules. Guests and others such as visiting speakers who are not full members of the exchange will be required to leave before such information is discussed.|
|Amber||Limited disclosure and restricted to members of the information exchange; those within their organisations and/or constituencies (whether direct employees, consultants, contractors or outsource-staff working in the organisation) who have a NEED TO KNOW in order to take action.|
|Green||Information can be shared with other organisations, information exchanges or individuals in the network security, information assurance or CNI community at large, but not published or posted on the web|