The “R” word that matters

Risk

Everything we covered so far, from accountability to IARs, naturally leads us to the most important “R” word when it comes to compliance: risk. There are numerous standards, methods, and templates for performing a risk assessment. Suggesting which method or framework you should use is out of the scope of this book. But we will put all the elements of risk analysis in place to give you enough clarity to get started with whatever method suits you. The goal is to make risk analysis sustainable, practical, and easy for everyone. To do that, let’s start with a simple definition:

Risk is the uncertainty of not achieving an objective.

For example, Zylker wants to increase its revenue by 200 percent in 2020.

The company’s main objective of boosting its revenue by 200 percent can be achieved through the four steps listed in the illustration above, and each of those steps has an objective. It’s important to note that achieving the objective also implies doing so in an effective and efficient manner such that the interests of the involved parties are not compromised.

Here's what we know about risk scenarios:

• Risk can never be eliminated but only minimized. The question is, how much do you need to minimize risk?
• Risk depends on your objective.

Ask yourself, Which scenarios would cause us to not meet our objective?

• All possible answers to the above question are your risks, and they need to be controlled.
• Each risk scenario needs at least one control.
• Even after applying the control, there will be risk. That is the residual risk, and it is your worst-case scenario.
• Risk scenarios will always be associated with impact. The impact will either directly or indirectly be on the asset associated with the activity.

Risk analysis in the 3P framework

The single unique unit of the 3P framework is an activity. How risk originates from each activity is best represented by this framework:

The above illustration is how each activity leads to risks and mandates controls. Controls ultimately decide how your organization will fare in complying with standards, because standards generally have a system of controls that you are expected to employ. Risk analysis, with activities as the origin point, will ensure those controls make sense for your organization.

The statement of applicability is the language through which your company and the external auditors converse. The system of controls that you derived through risk analysis will play a major part in arriving at the statement of applicability.

Making risk analysis scalable: Global and local risks

Clearly when there is an activity there is an objective and there will be risk. For an organization with hundreds of activities, there will be even more risks. With hundreds of accountable people thinking of even more risks, can this process really be scalable?

As necessary as risk analysis is, it is not practical to assume that every accountable person in your organization will do it effectively. There needs to be a system that can help them.

This system should be built to clarify risk analysis and provide it on a platter for anyone who wants to do it. A centralized risk registry with a coding system and categorization of risks is a good place to start.

The SPA touch: There is no better team than the SPA team to create a register that is suited for the entire organization. It should be up to the SPA team to maintain a risk registry that captures:

1. Global risks: Risks that affect the entire organization.

For example, a natural disaster like an earthquake would sabotage all of Zylker's operations. Likewise, a glitch on the internet service provider's end might result in Zylker's servers shutting down indefinitely. These types of risks could affect Zylker as a whole, and they apply to every team and individual.

When Dwayne is performing risk analysis for Zylker - Think, does it make sense for him to analyze all these global risks? Not really. That is why the SPA team must collaborate with other central teams and operations teams to form a comprehensive list of global risks and controls. These controls must be applied throughout the teams.

Dwayne can now simply refer to the SPA team's global risk register and mention those risks. He can focus on the risks specific to Zylker - Think alone, which are called local risks.

2. Local risks: Risks that are specific to activities and are identified by the accountable individuals.

A good way to approach local risks is through the three security principles: confidentiality, integrity, and availability (the CIA triad). To analyze the local risks related to Zylker - Think's evaluation module (refer to the DFD in Illustration 18 above), here's an approach:

Note: It is preferable to use a DFD for risk analysis, as it serves as a checklist for all scenarios that need to be considered.

• Due to a programming error, the record of one user may get mapped to the ID of another user. This could impact operations and privacy (confidentiality). Zylker mitigates this by having the SPA team create a checklist (control) that the developers must follow.
• A user record may become unavailable (availability) or damaged (integrity) due to an erroneous build update. Zylker makes backups (control) of its user data to ensure this does not affect the user.
• If the evaluation method or scoring criteria are changed, it might lead to obsolete data, as the results of old data will not be relevant anymore (integrity). Zylker migrates old data (control) to avoid this.

If you can see how the flow of data (DFDs) can be subjected to the CIA risks, few risks will miss your radar.

3. Risk ID: A coding system with unique IDs for risks will make it easier for the accountable individuals to identify and include risks that apply to their activities.

Here's what needs to be done:

• The SPA team creates a risk registry, assigning a separate risk ID and a tag to identify risks as local and global risks.
• The SPA team collaborates with various teams to identify global risks.
• Each accountable person refers to the risk registry and identifies the global risks applicable to their activities.
• Each accountable person then records the local risks applicable to their activities alone. These will also be given a risk ID and tagged.
• The SPA team approves local risks after performing a review.

This registry will enable you to filter out the risks specific to an activity, a set of activities, a business function, or a team. This makes risk analysis a scalable process.

Customizing risk analysis for audits: To make the best use of your risk assessment, you can classify risks further as suited to your organization.

Zylker's SPA team decides to categorize risks into business risks and compliance risks. Business risks are those events that may cause harm to aspects of the business like productivity, revenue, and customer sentiment. Compliance risks are when a particular risk fails the control of a standard. This differentiation helps Zylker during audits, since the organization can filter out compliance risks and treat them separately.

Similarly, Zylker has two types of controls: local controls and standard controls. Local controls can be changed to suit Zylker's operations, while standard controls are mapped to standards and cannot be changed without the approval of management and consultation with external auditors.

Where it all starts: Policies

Clearly, risks are derived from objectives. In Illustration 14, if you assemble the “Objective” part of all activities, you will have the list of things your company wants to achieve.

This list is the base of policies.

Policies are the values that your company stands for.

Each objective in that list is what your company wants to achieve, and the list helps you decide what your company stands for on its way to achieve its objectives.

Let’s assume Zylker wants to expand its business, and the organization’s upper management realizes that the sales and marketing teams need to step up to this challenge. The organization lists what it expects its sales and marketing teams to do:

• All of Zylker’s communications with prospects and customers will only be through one of the following channels: Zylker’s website, social media (Facebook, Twitter, blogs, LinkedIn), bulletins, webinars, brochures, giveaways, annual meetings, Zylker conferences, roadshows, contractual meetings, email, and phone calls.
• All external means of communication—print, electronic, verbal, etc.—shall be based on one of the six lawful bases of the GDPR. The appropriate lawful basis shall be recorded in the record of processing activities.
• One of the members of upper management will ensure that Zylker’s website is consistent in its branding and messaging. Any required changes to match the industry trends shall be discussed and accommodated.
• When presented to prospects, information regarding Zylker’s services will always be truthful. Relevant factors likely to affect the prospects' decisions shall be communicated in such a way and at such a time that prospects can take them into account.
• The pricing of services is subject to change with respect to the conditions of the market and shall be done based on the pricing guidelines of Zylker.
• In-person meetings, including those during events and conferences, shall be done in a conscientious and diligent manner such that the brand name and reputation of Zylker is not compromised.

The above is a non-exhaustive list of what every employee must know when carrying out sales and marketing activities for Zylker. Likewise, product development, administration, human resources, and other business functions can have their own policies that are published and shared with each employee at the company once approved.

Whether your activities are taking place according to your policies is a crucial consideration during any audit.

You can take two approaches when you want to frame policies:

Top-down: Upper management decides its stance with regards to various functions like sales, production, and operations. The objectives for activities will be decided by the accountable individuals.

Bottom-up: Policies are derived from the list of objectives. Common objectives are grouped, and the policy created will be a representation of all those objectives.

Risk scenarios and controls

Risk is how things can go wrong, and a control is a way to try and minimize the probability (minimize the impact and/or likelihood) that it can go wrong.

But whether a control is necessary or not depends on how you respond to the risk. You may decide to not employ a control when:

• The risk does not inflict any damage on an asset.
• The risk is unlikely to occur.
• The impact of the risk is so big that any control you can implement won’t protect you from it.
• The effort required to protect your assets against the risk is disproportionate to those assets’ value to the company.
• The consequences of the risk will not affect your objectives in a substantial manner.
• Your organization is willing to accept the consequences.

The decision to employ controls must be made by the accountable person and must be periodically reviewed by the SPA team.

Data protection impact assessments (DPIAs)

The Information Commissioner’s Office (ICO) has given an elaborate explanation for performing a DPIA, along with a template that you can use right away. However, let’s look into where a DPIA fits in your overall compliance framework.

A DPIA is a tool to help you identify and mitigate risks even before you begin processing personal data so that you can comply with Art. 25 of the GDPR, which mandates data protection by design and by default. It is similar to risk analysis but more focused on privacy and data protection laws.

Article 35(3) of the GDPR has laid out scenarios where a DPIA is mandatory: profiling, processing of biometric and genetic data, tracking, denial of service, AI and machine learning, invisible processing, and direct marketing.

However, from the perspective of compliance, it is safe to say that a DPIA is always advisable and is a logical part of the change management process.

Here are a few major changes your organization might face:

• Introducing a new technology like machine learning
• Conducting new operations
• Releasing new features in products
• Exploring new marketing tactics
• Conducting business in a new geographical area
• Partnering with a new company

All these above changes involve a modification to the way personal data is processed. A change like releasing a new feature may not directly involve personal data, but if you look closer, you’ll see that the feature itself may come in contact with personal data when customers use it.

So, it is preferable to stick to the first step of a DPIA for all changes: Identify the need for a DPIA.

DPIAs and IARs

The connection between DPIAs and IARs is the most logical connection between a DPIA and the 3P framework since it directly involves the flow of personal data.

If the change has to do with an operation in your company, a process IAR comes into the picture. If the change has to do with a new feature or product, a product IAR is more appropriate. Either way, your IAR, which focuses on the flow of personal data, is where you can start your DPIA.

Take the example of Illustration 14. Technically, every arrow that indicates a data flow and every box that indicates a process needs to be analyzed for risk. Each unit of the DFD can be interpreted from the following perspectives:

• The purpose of processing: Why the system collects the data it does.
• Storage: Where the data is stored (data center), how much it is protected in storage, how long it is stored, and who decides how and for how long it must be stored.
• Access control: Who has access, how and by who the access is monitored and reviewed, how much access is provided to which party on what basis, and how much access is needed for processes like support and debugging.
• Security: How secure the data is at rest and in transit, what features are provided, how the system can be abused and misused, and what controls are in place to prevent abuse and misuse.
• Data classification: What level of sensitive and personal data is involved, which data subjects are involved, what are the risks if this data is compromised, and how the system can detect and prevent compromise.
• Backup and recovery: How the system handles unprecedented loss or damage of data.
• Regulatory compliance: What rights data subjects can exercise on their data based on the applicable laws, and how the system provides such rights.