Privacy Risk Assessment and Treatment Process
ISO/IEC 27701 Toolkit: Version 2
Implementation guidance
The header page and this section, up to and including Disclaimer, must be removed from the final version of the document. For more details on replacing the logo, yellow highlighted text and certain generic terms, see the Completion Instructions document.
Purpose of this document
The Privacy Risk Assessment and Treatment Process documents how risk assessments will be carried out and the resulting risks treated.
Areas of the standard addressed
The following areas of the ISO/IEC 27701 standard are addressed by this document:
• 6 Planning
o 6.1 Actions to address risks and opportunities
▪ 6.1.1 General
▪ 6.1.2 Privacy risk assessment
▪ 6.1.3 Privacy risk treatment
• 8 Operation
o 8.2 Privacy risk assessment
o 8.3 Privacy risk treatment
General guidance
The risk assessment process underpins much of the ISO/IEC 27701 standard and it is worth spending some time to understand its main points. If you have a corporate risk assessment process within your organization then you should either adopt that or ensure that this process is in harmony with it.
There is an international standard for risk management which may be worth obtaining – ISO 31000. This is not required for ISO/IEC 27701 but gives the “official” view of how risk management should be carried out. It is supplemented by ISO/IEC 27557 which expands on how risk assessment applies specifically to privacy.
The important aspects are that you identify, assess and treat the risks, implementing appropriate controls which relate to the risk(s) they address. The ISO27701 standard requires that the potential impact of a risk on PII principals is considered as part of the process, and that the controls specified in Annex A of that standard are used to treat PIIrelated risks.
Note that this document gives the option of following either an asset-based or scenariobased risk assessment process, or a combination of the two
Review frequency
We would recommend that this document is reviewed annually.
Document fields
This document may contain fields which need to be updated with your own information, including a field for Organization Name that is linked to the custom document property “Organization Name”.
To update this field (and any others that may exist in this document):
1. Update the custom document property “Organization Name” by clicking File > Info > Properties > Advanced Properties > Custom > Organization Name.
2. Press Ctrl A on the keyboard to select all text in the document (or use Select, Select All via the Editing header on the Home tab).
3. Press F9 on the keyboard to update all fields.
4. When prompted, choose the option to just update TOC page numbers.
If you wish to permanently convert the fields in this document to text, for instance, so that they are no longer updateable, you will need to click into each occurrence of the field and press Ctrl Shift F9.
If you would like to make all fields in the document visible, go to File > Options > Advanced > Show document content > Field shading and set this to “Always”. This can be useful to check you have updated all fields correctly.
Further detail on the above procedure can be found in the toolkit Completion Instructions
This document also contains guidance on working with the toolkit documents with an Apple Mac, and in Google Docs/Sheets.
Copyright notice
Except for any specifically identified third-party works included, this document has been authored by CertiKit, and is ©CertiKit except as stated below. CertiKit is a company registered in England and Wales with company number 6432088.
Licence terms
This document is licensed on and subject to the standard licence terms of CertiKit, available on request, or by download from our website. All other rights are reserved. Unless you have purchased this product you only have an evaluation licence.
If this product was purchased, a full licence is granted to the person identified as the licensee in the relevant purchase order. The standard licence terms include special terms relating to any third-party copyright included in this document.
Disclaimer
Please Note: Your use of and reliance on this document template is at your sole risk. Document templates are intended to be used as a starting point only from which you will create your own document and to which you will apply all reasonable quality checks before use.
Therefore, please note that it is your responsibility to ensure that the content of any document you create that is based on our templates is correct and appropriate for your needs and complies with relevant laws in your country.
You should take all reasonable and proper legal and other professional advice before using this document.
CertiKit makes no claims, promises, or guarantees about the accuracy, completeness or adequacy of our document templates; assumes no duty of care to any person with respect its document templates or their contents; and expressly excludes and disclaims liability for any cost, expense, loss or damage suffered or incurred in reliance on our document templates, or in expectation of our document templates meeting your needs, including (without limitation) as a result of misstatements, errors and omissions in their contents.
Privacy Risk Assessment and Treatment Process
[Insert classification]
Privacy Risk Assessment and Treatment Process
DOCUMENT CLASSIFICATION [Insert classification]
DOCUMENT REF PIMS-DOC-06-3
VERSION 1
DATED [Insert date]
DOCUMENT AUTHOR [Insert name]
DOCUMENT OWNER [Insert name/role]
Revision
Distribution
NAME
Approval
NAME
Table 4: RACI chart..................................................................................................................... 23
2.2 Risk acceptance criteria
One of the options when evaluating risks is to do nothing i.e. to accept the risk. This is a valid approach but must be used with caution. The circumstances under which risks may be accepted must be fully agreed and understood.
Criteria for accepting risks will vary according to several factors which may change over time. These include the organization’s general or cultural attitude to risk, the prevailing financial climate, legal and regulatory requirements, the current view of top management and the sensitivity of the specific assets, PII or business areas within scope.
Before carrying out a risk assessment the criteria for accepting risks must be discussed by appropriate people with knowledge of the subject area and, if necessary, top management. This discussion should establish guidelines for the circumstances in which risks will be accepted i.e. not subjected to further treatment.
These criteria may be expressed in several different ways, depending on the scope of the risk assessment and may include situations where:
• The cost of an appropriate control is judged to be more than the potential loss
• Known changes will soon mean that the risk is reduced or disappears completely
• The risk is at or lower than a defined threshold, expressed either as a level e.g. low or as a quantified amount e.g. a financial sum
• An area is known to be high risk but also high potential reward i.e. it is a calculated risk
These acceptance criteria must be documented and used as input to the risk evaluation stage of the assessment process.
2.3 Process diagram
Figure 1: Risk assessment and treatment process diagram
2.4 Establish the context
The overall environment in which the risk assessment is carried out must be described and the reasons for it explained. This should include a description of the internal and external context and any recent changes that affect the likelihood and impact of risks in general.
The internal context may include:
• Governance, organizational structure, roles and accountabilities
• Policies, objectives, and the strategies that are in place to achieve them
• The capabilities, understood in terms of resources and knowledge (e.g. capital, time, people, processes, systems and technologies)
• Information systems, information flows and decision-making processes (both formal and informal)
• The sensitivity of PII involved, for example if it is defined as special category by relevant privacy legislation
• Relationships with, and perceptions and values of, internal stakeholders
• The organization's culture
• Standards, guidelines and models adopted by the organization
• Form and extent of contractual relationships
• The type(s) of cloud services provided
The external context may include:
The cultural, social, political, legal, regulatory, financial, technological, economic, natural and competitive environment, whether international, national, regional or local
• Key drivers and trends having impact on the objectives of the organization
• Relationships with, and perceptions and values of, external stakeholders
• The prevailing market or industry view of the security of cloud service providers –this may be affected by any recent breaches involving the loss of PII
The scope of the risk assessment must also be defined. This may be expressed in terms of factors such as:
• Geographical location e.g. countries, offices, data centres
• Organizational units e.g. specific departments
• Business process(es)
• IT services, systems and networks
• Customers, products or services
• Specific sets of PII and its processing
2.5 Risk identification
The process of identifying risks to be assessed will consist of the following steps in line with the requirements of ISO/IEC 27701
[Note – there is a wide variety of risk identification approaches you could use and we do not list them all here. Instead, two common approaches are proposed: asset-based (usually more detailed) and event-based, a more high-level approach). The ISO/IEC 27701 standard does not specify a particular approach so either (or a combination of the two) is acceptable for certification purposes.]
2.5.1 Compile/maintain PII asset inventory
A full inventory of PII assets is compiled and maintained by [Organization Name]. This will include PII that [Organization Name] stores and processes in its role as a PII controller or processor. Access to an inventory of the systems, software and hardware components that support the processing of that PII may also be required
The list of assets is held in the document PII Asset Inventory as part of the PIMS and includes relevant information about each asset, including:
• A description of the PII asset
• The business process it relates to
• Whether it is classed as special category PII under applicable legislation
• The location(s) of the PII principals
• How and where the PII is stored and processed
• The controls currently applied to the PII
Each PII asset has an owner who should be involved in the risk assessment for that asset. Where appropriate for the purposes of risk assessment, cloud customer data assets may be owned by an internal role and the customer consulted regarding the value of those assets.
For the purposes of risk assessment, it may be appropriate to group assets with similar requirements together so that the number of risks to be assessed remains manageable.
[Note - if you choose to conduct an asset-based risk assessment the following sections will apply:]
2.5.2 Identify potential threats
For each asset (or asset group), the threats that could be reasonably expected to apply to it will be identified. These will vary according to the type of asset and could be accidental events such as fire, flood or vehicle impact or malicious attacks such as viruses, theft, or sabotage.
2.5.3
Assess existing vulnerabilities
Attributes of an asset (or asset group) which may be exploited by any specific threat are referred to as vulnerabilities and will be detailed as part of the risk assessment.
Examples of such vulnerabilities may include a lack of patching on servers (which could be exploited by the threat of malware) or the existence of paper files in a data centre (which could be exploited by the threat of fire).
[Note – if you choose to conduct an event-based risk assessment the following section will apply:]
2.5.4 Identify risk scenarios
The identification of risks to the privacy management of the organization will be performed by a combination of group discussion and interview with interested parties.
Such interested parties will normally include (where possible):
• Manager(s) responsible for each business activity that involves PII processing
• Representatives of the people that normally carry out each aspect of the activity
• Providers of the inputs to the activity
• Recipients of the outputs of the activity
• Appropriate third parties with relevant knowledge
• Representatives of those providing supporting services and resources to the activity
• Any other party that is felt to provide useful input to the risk identification process
Identified risks will be recorded with as full a description as possible that allows the likelihood and impact of the risk to be assessed. Each risk must also be allocated an owner.
[Note – the rest of the document applies to both risk assessment approaches:]
2.6 Risk analysis
Risk analysis within this process involves assigning a numerical value to the a) likelihood and b) impact of a risk. These values are then multiplied to arrive at a classification level of high, medium, or low for the risk.
2.6.1
Assess the likelihood
An estimate of the likelihood of a risk occurring must be made. This should consider whether it has happened before either to this organization or similar organizations in the
same industry or location and whether there exists sufficient motive, opportunity and capability for a threat to be realized.
The likelihood of each risk will be graded on a numerical scale of 1 (low) to 5 (high). General guidance for the meaning of each grade is given in Table 1. When assessing the likelihood of a risk, existing controls will be considered. This may require an assessment to be made as to the effectiveness of existing controls.
More detailed guidance may be decided for each grade of likelihood, depending on the subject of the risk assessment.
GRADE DESCRIPTION
SUMMARY
1 Improbable Has never happened before and there is no reason to think it is any more likely now
2 Unlikely There is a possibility that it could happen, but it probably won't
3 Likely On balance, the risk is more likely to happen than not
4 Very Likely It would be a surprise if the risk did not occur either based on past frequency or current circumstances
5 Almost certain Either already happens regularly or there is some reason to believe it is virtually imminent
Table 1: Risk likelihood guidance
The rationale for allocating the grade given should be recorded to aid understanding and allow repeatability in future assessments.
2.6.2 Assess the impact
An estimate of the impact that the risk could have on PII principals and on the organization must be given. This should consider existing controls that lessen the impact, as long as these controls are seen to be effective.
Impact on PII principals
When assessing the potential impact on PII principals, consideration will be given to possible harm in the following areas (based on guidance in ISO/IEC 27557 Annex C):
• Dignity loss – embarrassment and loss of reputation or standing in the community
• Discrimination – unfair treatment from others based on the nature of the PII involved
• Economic loss – direct financial cost, for example due to fraud, or inability to be treated fairly with regard to finance
• Loss of self-determination – affecting control over personal circumstances, loss of freedom or physical harm
• Loss of trust – feelings of unfair treatment resulting in behavioural changes
The level of impact in each area will be assessed with regard to the following levels:
DESCRIPTION
1 Negligible The PII principal is unlikely to notice or feel any inconvenience or effect.
2 Slight If the PII principal is affected at all, it is a minor inconvenience and causes little disruption.
3 Limited PII principals suffer significant inconveniences but they are surmountable with moderate effort.
4 Significant Impacts on PII principals are only overcome with real and serious difficulty.
5 Maximum PII principals suffer major and possibly irreversible impacts which may be very difficult or impossible to overcome.
Specific criteria may be defined in each area where this is helpful, for example economic loss may be defined in terms of amounts of money.
Impact on the organization
When assessing the potential impact on the organization, consideration will be given to possible harm in the following areas (based on guidance in ISO/IEC 27557 Annex C):
• Noncompliance costs – fines and expenses resulting from legal action and remediation
• Direct business costs – loss of revenue or profit or increased costs of doing business
• Damage to reputation – loss of customer trust and brand value
• Harm to internal organizational culture – reduced organizational performance, lower employee morale or ethical conflict
The level of impact in each area will be assessed with regard to the following levels:
Table 2 - PII principal impact levels
DESCRIPTION
1 Negligible The organization is unlikely to notice or feel any inconvenience or effect.
2 Slight A minor inconvenience to the organization which causes little disruption and is easily managed.
3 Limited Significant organizational issues arise, but they are surmountable with moderate effort.
4 Significant Impacts on the organization are only overcome with real and serious difficulty.
5 Maximum The organization suffers major and possibly irreversible impacts which may be very difficult or impossible to overcome.
More detailed guidance may be defined for each grade of impact in each area, for example noncompliance costs may be quantified in monetary ranges, depending on the subject of the risk assessment. The rationale for allocating the grade given in each of the two areas should be recorded to aid understanding and allow repeatability in future assessments.
In calculating the risk score (and therefore risk classification), the higher of the two impacts (PII principal and organizational) will be used.
2.6.3 Risk classification
Based on the assessment of the grade of likelihood and impact, a score is calculated for each risk by multiplying the likelihood by the greater of the two impacts. This resulting score is then used to decide the classification of the risk based on the matrix shown in figure 2.
Each risk will be allocated a classification based on its score as follows:
• High: 12 or more
• Medium: 5 to 10 inclusive
• Low: 1 to 4 inclusive
[Note – you may decide to change the definition of high, medium and low classifications based on your general risk appetite e.g. you may decide that only risks with a score of 16 or more will be classified as high.]
Table 3 - Organization impact levels
RISK IMPACT: How severe could the consequences be if the risk event happened? RISK LIKELIHOOD: What are the chances of the risk event happening?
The classification of each risk will be recorded as input to the risk evaluation stage of the process.
2.7 Risk evaluation
The purpose of risk evaluation is to decide which risks can be accepted and which ones need to be treated. This will consider the risk acceptance criteria established for this specific risk assessment (see Risk Acceptance Criteria, above).
The matrix in Figure 2 shows the classifications of risk, where green indicates that the risk is below the acceptable threshold. The orange and red areas generally indicate that a risk does not meet the acceptance criteria and so is a candidate for treatment.
Risks will be prioritized for treatment according to their score and classification so that very high scoring risks are recommended to be addressed before those with lower levels of exposure for the organization.
Figure 2: Risk matrix chart
2.7.1 Risk assessment report
The output from the risk evaluation stage is the risk assessment report. This shows the following information:
• Assets [asset-based risk assessment only]
• Threats [asset-based risk assessment only]
• Vulnerabilities [asset-based risk assessment only]
• Risk scenario descriptions [event-based risk assessment only]
• Controls currently implemented
• Likelihood (including rationale)
• Impact (including rationale)
• Risk Score
• Risk Classification
• Risk Owner
• Whether the risk is recommended for acceptance or treatment
• Priority of risks for treatment
This report is input to the risk treatment stage of the process and must be signed off by management before continuing, particularly in respect of those risks that are recommended for acceptance.
2.8 Risk treatment
For those risks that are agreed to be above the threshold for acceptance by [Organization Name], the options for treatment will then be explored.
The overall intention of risk treatment is to reduce the classification of a risk to an acceptable level. This is not always possible as sometimes although the score is reduced, it remains in the same classification e.g. reducing the score from 8 to 6 means it remains a medium level risk. The organization may decide to accept these risks even though they remain at a medium rating. Such decisions must be recorded with a suitable explanation.
2.8.1 Risk treatment options
The following options may be applied to the treatment of the risks that have been agreed to be unacceptable:
1. Modify the risk - apply appropriate controls to lessen the likelihood and/or impact of the risk
2. Avoid the risk by taking action that means it no longer applies
3. Share the risk with another party e.g. insurer or supplier
Judgement will be used in the decision as to which course of action to follow, based on a sound knowledge of the circumstances surrounding the risk, for example:
• Business strategy
• Regulatory and legislative considerations
• Technical issues
• Commercial and contractual issues
• Impacts on PII principals
The PIMS Manager will ensure that all parties who have an interest or bearing on the treatment of the risk are consulted, including the risk owner.
2.8.2 Selection of controls
In accordance with [Organization Name]’s adoption of the ISO/IEC 27701 standard, Annex A of that document will be used as the starting point for the identification of appropriate controls to address the risk treatment requirements identified as part of the risk assessment exercise.
The controls set out in the above standard may be supplemented by the extended and additional guidance set out in the following codes of practice:
• ISO/IEC 27002 – Code of practice for information security controls
• ISO/IEC 27017 – Code of practice for information security controls based on ISO/IEC 27002 for cloud services
• ISO/IEC 27018 – Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors
The last two of these provide specific application of the ISO/IEC 27002 controls to a cloud service provider scenario and address the area of the protection of PII more comprehensively than the ISO/IEC 27701 standard on its own.
2.8.3 Risk treatment plan
The evaluation of the treatment options will result in the production of the risk treatment plan which will detail:
• Risks requiring treatment
• Risk owner
• Recommended treatment option
• Control(s) to be implemented
• Responsibility for the identified actions
• Cost estimate for implementing the control(s)
• Timescales for actions
• Expected residual risk levels after the controls have been implemented
2.8.4 Statement of applicability
The Statement of Applicability will set out those controls from Annex A of the ISO/IEC 27701 standard that have been selected and the reasons for their selection. It will also detail those that have been implemented and identify any that have been explicitly excluded together with a reason for such exclusion.
2.9 Management approval
At each stage of the risk assessment process management will be kept informed of progress and decisions made, including formal signoff of the proposed residual risks. Management will approve the following documents:
• Risk Assessment Report
• Risk Treatment Plan
• Statement of Applicability
Signoff will be indicated according to [Organization Name] documentation standards. In addition to overall management approval, the acceptance or treatment of each risk must be signed off by the relevant risk owner.
2.10 Risk monitoring and reporting
As part of the implementation of new controls and the maintenance of existing ones, key performance indicators will be identified which will allow the measurement of the success of the controls in addressing the relevant risks.
These indicators will be reported on a regular basis and trend information produced so that exception situations can be identified and dealt with as part of the management review process of the PIMS.
2.11 Regular review
In addition to a full annual review, risk assessments will be evaluated on a regular basis to ensure that they remain current and the applied controls valid. The relevant risk assessments will also be reviewed upon major changes to the business such as office moves, mergers and acquisitions or introduction or new or changed IT services.
2.12 Roles and responsibilities
Within the process of risk assessment there are several key roles that play a part in ensuring that all risks are identified, addressed and managed. These roles are shown in the RACI table below, together with their relative responsibilities at each stage of the process.
2.12.1 RACI chart
The table below clarifies the responsibilities at each step using the RACI model, i.e.:
• R: Responsible
• A: Accountable
• C: Consulted
• I: Informed
Table 4: RACI chart
Further roles and responsibilities may be added to the above table as the risk assessment and treatment process matures within [Organization Name]
