Cloud 101CircleEventsBlog
Register for CSA’s free Virtual Cloud Trust Summit to tackle enterprise challenges in cloud assurance.

5 Common Problems in ISO 27701 Certifications

5 Common Problems in ISO 27701 Certifications

Blog Article Published: 12/12/2022

Originally published by Schellman.

Written by James Hunter, Schellman.

If you’ve ever been in a car with someone who takes a speedbump anywhere above 10mph, at the time, you’ve probably thought, “didn’t you see that coming?!” Or maybe, “why didn’t they avoid that giant bump in the road?”

Speedbumps in the road should be easy—they’re usually painted a bright color to draw the attention of unsuspecting drivers. But the same can’t be said for the problems that slow down ISO 27701 certifications. Many times, they just crop up suddenly, derailing your hopes of providing privacy assurances to your customers (at least temporarily).

In this article, we’ll go over 5 common issues that our ISO team frequently identifies during the ISO 27701 certification process. By addressing these ahead of your organization’s initial certification or scope expansion, you can help your process proceed smoothly and more efficiently.

5 Common Gaps in ISO 27701 Certifications

1. PIMS Scoping and Documentation Issues

Scoping is so delicate with all compliance initiatives, it’s no wonder that organizations run into problems scoping their ISO 27701 privacy information management system (PIMS) too.

The PIMS is an extension of your ISO 27001 information security management system (ISMS), so when you go about defining its scope/boundaries in the context of the processing of personal data, remember this:

  • The PIMS scope can be narrower than that of the ISMS, but it cannot be broader.
  • It also may be narrower than your privacy program as a whole.
    • If a particular system, process, or application is not in the scope of the ISMS, then it cannot be included in the PIMS scope (though it may be part of your overall privacy program.)
      • For example, your marketing activities may fall within the scope of your privacy program but may fall outside the bounds of your ISMS. So those activities could not be included in the PIMS (unless you extended your ISMS to include marketing).

As you create and define these boundaries, you’ll face a key decision point: Do you fold the PIMS requirements into existing ISMS documentation or create standalone documentation?

  • The case for folding in:
    • If your ISMS / PIMS is one combined management system, you should be able to easily incorporate the PIMS scope into the ISMS documentation.
    • You avoid the efforts of duplicative documentation and can also consolidate updating both sets for relevant changes.
  • The case for additional documents:
    • You’d be less likely to miss/exclude areas regarding PIMS/ISO 27701/privacy references.

Other common issues we see regarding the scope frequently include:

  • No details documenting the needs and expectations of interested parties concerning PII principals (defined by ISO as the data subjects to whom the PII pertains).
  • Missing information detailing requirements with respect to PII principal expectations regarding the processing of PII.
2. Flaws in the ISO 27701 Risk Assessment

Another key item to get right is your ISO 27701 risk assessment. You’re required to do one, and it can either stand alone or be integrated into your security risk assessment process. The 27701 risk assessment requirements include:

  • Identifying the applicable controls in Annexes A and B of ISO 27701 that help mitigate personally identifiable information (PII)-related risks; and
  • Addressing the impact of the risk for PII principals and their data.

Your 27701 risk assessment must include the following:

  • Risk Identification: How do you identify risks and potential threats to your processing of PII?
  • Risk Analysis: How do you identify the likelihood and impact of a risk or threat occurring?
  • Risk Documentation: How do you track, record, and assign owners to risks?
  • Risk Treatment: How are risks mitigated? How are controls selected and implemented to lower the risk likelihood or impact?
3. Incorrectly Documented Statement of Applicability

Once you’ve completed a risk assessment, you’ll move on to the required statement of applicability (SOA). Your SOA should tie back to the risk assessment and document the current control environment, not a future state. It should not capture an anticipated circumstance or state—this is often a big issue in SOAs.

(E.g., if you do not currently process data jointly, then the control should be N/A. Just because there could be a situation in the future does not make it applicable now.)

Core components of your SOA—to be documented in a current state—include:

  • Your implemented controls and their justifications
  • The reasoning for all excluded controls
  • The implementation status of controls
4. Lack of Internal Audit and Management Review

For you to extend your ISMS to include a PIMS—and extend your ISO 27001 certificate to include ISO 27701—you must first undergo an internal audit (IA) against the ISO 27701 requirements.

This should occur after the risk assessment (mentioned in #2) has been conducted.

You should perform this internal audit to verify that:

  • In-scope controls are appropriate and functioning; and
  • ISO 27701 requirements and controls are met.

This’ll also help to confirm that no necessary controls have been omitted. As a reminder, once the internal audit has been performed, the PIMS must still go through the established management review process. Though you’ll be evaluating the suitability, adequacy and effectiveness of the PIMS, this process should consider the same topics covered during the same for the ISMS.

5. Commonly Misunderstood Controls in Clauses 7 and 8

ISO standards being as comprehensive as they are, it should be no surprise that some controls are sometimes missed or misunderstood. Let us clear up some common misconceptions so you can avoid issues with these controls:

Joint Controller
(7.2.7)

You should have specific joint-controller agreements established that document the roles and responsibilities for the processing of PII.

It’s a common pitfall to indicate that Clause 7.2.7 is applicable based on the potential for a future joint controller relationship, but remember, the SOA’s applicable controls should reflect the management system’s current state.

Temporary Files (7.4.6/8.4.1)

You will need to include database logs that may contain PII, as well as files specific to the system or application created in the normal course of business (e.g., metadata).

A key factor is that temporary files are not needed after associated task has been completed. ISO 27701 doesn’t define a retention time requirement but does state that you can rely on procedures for “garbage collection” to identify these temporary files.

Basis for PII Transfer Between Jurisdictions (7.5.1/8.5.1)

Recall Schrems II—a July 2020 decision by the Court of Justice of the EU that struck down the Privacy Shield framework, thereby complicating the flow of personal data between the US and EU and calling into question the sufficiency of Standard Contractual Clauses (SCCs).

That decision has since caused some confusion regarding these requirements. To avoid that:

  • Do not rely on outdated SCCs.
  • Implement a real mechanism for informing customers of any changes to the basis.
  • Determine if you have a process in place to address transfer considerations (e.g., transfer impact assessments).
  • A process to record PII disclosures; and
  • A process in place to track any disclosures that have occurred (this includes and is especially important for legally binding disclosures).

Infringing Instruction (8.2.4)

Oftentimes, there’s an attempt to rely on language in a standard data processing agreement (DPA) here, and that’s not typically sufficient for ISO 27701.

You must have a process to identify and handle a processing request that could be considered “infringing.”

Records of PII Disclosure to Third Parties (8.5.3)

To satisfy this requirement, you must have:

Disclosure of Subcontractors Used to Process PII (8.5.6)

Change of a Subcontractor to Process PII (8.5.8)

You must clearly disclose subprocessors, as well as any changes to subprocessors used to process PII.

As evidence, you can use a documented list of subprocessors that includes how PII is provided to them, as well as how previous changes in subprocessors were communicated.

Next Steps for Your ISO 27701 Certification

Aside from these, several other, general issues we find during the certification process include:

  • An overreliance on contractual agreements and the privacy notice
    • While these documents are key to defining privacy obligations and responsibilities, you should record additional policies and procedures to demonstrate how you communicate, support, and implement these privacy obligations requirements.
  • Failure to consider or misunderstanding applicable legislation/regulations
    • Organizations sometimes think ISO 27701 equates to compliance with a particular law or privacy regulation. And while the implementation guidance does reference laws/regulations, don’t make the mistake of failing to consider other applicable regulations—you might meet a control without actually meeting a legal requirement.
    • The opposite is also true—you’ve chosen to go through this certification, so you cannot disregard a control requirement just because it’s not a legal requirement from another regulation that you’re subject to. If your risk assessment process has denoted a control requirement as applicable, you will be held accountable for implementation.

All of these issues can hinder a smooth ISO 27701 process, but now that you have this list of items to avoid, you should be better positioned than most to avoid these possible “speedbumps.”

Share this content on your favorite social network today!