InfoSec Compliance & AI Governance For over 20 years, DISC InfoSec has been a trusted voice for cybersecurity professionals—sharing practical insights, compliance strategies, and AI governance guidance to help you stay informed, connected, and secure in a rapidly evolving landscape.
GDPR Isn’t a Cookie Banner: The Audit Findings That Actually Get Companies Fined
Seven years after GDPR took effect, most organizations still treat it like a checkbox they ticked in 2018. They dropped in a cookie banner, published a privacy policy their own lawyers haven’t read since, and moved on. Then a data subject access request lands, or a breach hits, or a regulator comes knocking — and suddenly the gap between “we have a privacy policy” and “we can actually demonstrate compliance” becomes very, very expensive. The uncomfortable truth I keep running into in audits is that GDPR failures rarely look dramatic. They’re not master hackers exfiltrating databases. They’re mundane, systemic gaps that sat quietly in plain sight until the day they didn’t. And with AI now feeding on personal data for marketing, sales, and product decisions, the old gaps have gotten wider and the new ones are appearing faster than most compliance programs can track.
Here’s what I actually find when I open the hood — and, more importantly, how to fix it.
Finding #1: No Defensible Lawful Basis (Especially for AI)
What I find: Organizations collect personal data across forms, chat, analytics, and enrichment tools without a documented lawful basis for each processing activity. When AI enters the picture, this gets worse — data collected for support or account management quietly gets repurposed to train or run marketing models, with no fresh basis and no assessment. “Legitimate interest” is invoked as a magic phrase, but no Legitimate Interest Assessment (LIA) exists to back it up.
Why it matters: Lawful basis is the foundation of the entire regulation. Without it, every downstream activity is built on sand — and repurposing data for AI without a compatible basis is one of the fastest-growing enforcement themes in Europe.
How to remediate: Build a processing inventory that maps each data type to a specific lawful basis. Where you rely on legitimate interest, write the LIA — a genuine three-part balancing test, not a paragraph. For any AI use, treat it as its own processing activity: document the basis for feeding personal data into the model, and never assume that consent for one purpose covers another.
Finding #2: The Privacy Notice Doesn’t Match Reality
What I find: The privacy policy describes a company that stopped existing years ago. It doesn’t mention the AI tools now processing customer data, doesn’t name key processors, and says nothing about profiling or automated decision-making. It’s transparency theater — technically present, functionally useless.
Why it matters: Transparency is a legal obligation, not a courtesy. If you’re using AI to score, segment, or make decisions about people, they have a right to know — in plain language — what’s happening and what it means for them.
How to remediate: Rewrite the notice to reflect current reality. Disclose AI processing explicitly, describe what the AI does with personal data, name your processor categories, and clearly explain any profiling and its likely consequences. Then put a recurring review on the calendar — a privacy notice is a living document, not a monument.
Finding #3: Data Subject Rights Requests Can’t Reach the AI Layer
What I find: The company can pull a record from the CRM when someone files an access or erasure request — but has no idea how to locate that person’s data inside the AI system, its logs, or its training set. Worse, when someone objects to marketing or profiling, the objection updates a flag in one system while the AI keeps processing them unchanged.
Why it matters: Rights that stop at the CRM aren’t rights. “We can’t delete that from the model” is a finding, not an acceptable answer — and an objection that doesn’t actually stop processing is a live violation every day it persists.
How to remediate: Map where personal data flows across every system, including the AI layer and its logs. Build rights fulfillment that propagates: an objection or erasure request must reach — and take effect in — the AI system, not just the primary database. Where model training makes deletion technically hard, document your handling approach in advance rather than improvising under a 30-day clock.
Finding #4: Vendor Contracts and Transfers Left Unmanaged
What I find: Personal data flows to a stack of third parties — AI vendors, ad platforms, analytics, enrichment services — often without signed Article 28 Data Processing Agreements. The AI vendor’s terms are unread, meaning nobody actually knows whether the vendor is training its own models on the company’s data. And data routinely leaves the EEA (frequently via US-based AI providers) with no valid transfer mechanism and no Transfer Impact Assessment.
Why it matters: You remain accountable for personal data even after it leaves your systems. An unread AI vendor contract that permits training on your data can turn your customers’ information into someone else’s product — and undocumented international transfers are a well-established enforcement target.
How to remediate: Inventory every processor and sub-processor. Get signed DPAs in place, and read the AI vendor’s terms specifically for whether your data trains their models — get that prohibited in writing if it isn’t already. For any transfer outside the EEA, confirm a valid mechanism (SCCs or adequacy) and complete a Transfer Impact Assessment for high-risk vendors.
Finding #5: No DPIA for High-Risk Processing
What I find: The organization is doing exactly the kind of large-scale profiling and automated decision-making that makes a Data Protection Impact Assessment mandatory under Article 35 — and no DPIA exists. There’s also no Record of Processing Activities that includes the AI, so when a regulator asks the company to demonstrate compliance, there’s nothing to hand over.
Why it matters: GDPR runs on accountability. It’s not enough to be compliant; you have to be able to prove it. A missing DPIA on high-risk AI processing is both a violation in itself and a signal to any regulator that the deeper controls probably aren’t there either.
How to remediate: Run the DPIA before scaling the AI initiative, not after. Document the processing, the risks to individuals, and the mitigations — and consult your DPO. Update the Article 30 Record of Processing Activities to include the AI. These artifacts are the evidence that turns “we think we’re compliant” into “here’s the file.”
My Perspective
After enough of these audits, a pattern becomes impossible to ignore: GDPR compliance almost never fails on the technology. It fails on the paper trail and the follow-through. The encryption is usually fine. What’s missing is the documented lawful basis, the honest privacy notice, the rights process that actually reaches every system, and the evidence that ties it all together. GDPR is, at its core, an accountability regime — and accountability is exactly the muscle most organizations skipped building.
AI has raised the stakes considerably. The same discipline GDPR has demanded since 2018 — know your data, justify your processing, honor people’s rights, prove it — is now the same discipline that frameworks like ISO 42001 and the EU AI Act demand for AI systems. That’s not a coincidence; it’s convergence. The companies that treated GDPR as a genuine data-governance practice rather than a cookie banner are the ones now absorbing AI governance almost effortlessly. The ones that faked it in 2018 are discovering there’s nothing underneath to build on.
My advice is simple and unglamorous: stop auditing for the banner and start auditing for the evidence. Can you produce your lawful basis, your DPIA, your vendor DPAs, and your rights-fulfillment records on demand? If yes, you’re most of the way there. If not, that gap won’t announce itself — until the day a request, a breach, or a regulator forces it into the open. Fix it while it’s still your choice.
How to Build a Master Questionnaire as Your Single Source of Truth for ISO 27001, ISO 42001, NIST 800-53, and GDPR
I want to tell you about a problem that is quietly draining compliance teams at SaaS companies right now — and a structural fix that changed how we think about audits entirely.
Here is the situation most security and compliance leaders find themselves in. You hold ISO 27001 certification. Your enterprise customers require NIST 800-53 Rev 5 verification. GDPR applies because you handle European personal data. And now, with AI baked into your product, ISO 42001 is on the table too. Four frameworks. Four sets of controls. Four different auditors asking different versions of the same fundamental questions.
The instinctive response is to build four compliance programs — one for each standard. Four spreadsheets, four evidence libraries, four cycles of internal prep, four rounds of answering the same question about your access control policy worded slightly differently each time.
We did this at client. It was expensive, repetitive, and structurally fragile. Every time a policy changed, we had to update it in four places. Evidence collected for one audit sat invisible to the others. The left hand genuinely did not know what the right hand was doing.
Then we asked a different question: What if there was only one audit?
The Insight That Changes Everything
Across ISO 27001:2022, ISO 42001:2023, NIST SP 800-53 Rev 5, and GDPR, the vast majority of what auditors actually want to know falls into the same 18 operational domains: governance, risk management, access control, data protection, cryptography, incident response, business continuity, supplier management, secure development, and so on.
The standards differ in language, structure, and emphasis. But the underlying security and privacy reality they are probing — your policies, your controls, your evidence — is the same reality. An ISO 27001 auditor asking about your access control policy (A.5.15) and a NIST assessor asking about AC-1 are fundamentally asking the same organization the same question. Your Access Control Policy v1.3 answers both of them.
This is the foundation of the Master Questionnaire approach: write the question once, map the answer to every standard it satisfies simultaneously.
Why Most Multi-Standard Programs Fail Structurally
Before describing what to build, it is worth being precise about why the typical approach breaks down. The problem is not effort or intention — compliance teams work hard. The problem is architecture.
Most organizations build what I call parallel catalogs: one spreadsheet or GRC module per standard, each with its own question set, its own evidence columns, its own status tracking. When the ISO 27001 auditor asks about incident response and the GDPR auditor asks about breach notification, they get two separate answers pointing to the same IR Procedure — but there is no structural connection between them. If you update the procedure, you have to remember to update both rows in both sheets. You usually do not. Inconsistencies accumulate. Auditors notice.
The second failure is ID scheme collision. This sounds technical but it matters enormously in practice. If your internal questionnaire uses “IR-01” for your Incident Response domain questions and NIST SP 800-53 uses “IR-1” for the same family, you end up with ID conflicts that make cross-referencing impossible. You cannot write a formula or filter that reliably maps one to the other. We ran into exactly this problem in our own workbook, discovering 173 NIST Moderate baseline controls that existed only in a standalone NIST catalog with no connection whatsoever to the master question set.
The third failure is scope mismatch. NIST SP 800-53 Rev 5 Moderate baseline has approximately 235 distinct controls across 20 families when enhancements are included. ISO 27001:2022 has 93 Annex A controls. ISO 42001:2023 has 38 AI-specific controls. GDPR has 99 Articles. Organizations routinely under-scope their questionnaires, sampling 26 or 30 NIST controls and calling it “covered.” A real Moderate baseline assessment covers every control — AC-1 through SR-12, including every enhancement number that the baseline requires.
The Architecture of a Single Source of Truth
Here is how to build it correctly.
Start with 18 operational domains, not four standards.
The domains should reflect how your organization actually operates: Governance & Policies, Scope & Context, Risk Management, Access Control & Identity, Data Protection & Privacy, Cryptography & Key Management, Network & Infrastructure Security, Secure Development, Incident Response, Business Continuity, Supplier & Third-Party Management, Physical & Environmental Security, Human Resources Security, Audit Logging & Monitoring, Configuration & Change Management, AI Governance, Compliance & Internal Audit, and Cross-Border Data Transfers.
Every question you write lives in one of these domains. The domain structure is standard-agnostic — it reflects your operational reality, not any single framework’s chapter structure.
Write questions that satisfy multiple standards simultaneously.
Take access control as an example. Rather than writing four separate questions — one citing ISO 27001 A.5.16, one citing NIST AC-2, one citing GDPR Art. 32, one citing ISO 42001 A.6.2.2 — you write one question: “Describe the complete joiner-mover-leaver process. How are accounts created, modified, and deactivated? What is the maximum time to deprovision a terminated user?”
This single question satisfies ISO 27001:2022 A.5.16 and A.5.18, NIST SP 800-53 Rev 5 AC-2, AC-2(1), AC-2(3), and AC-2(5), and GDPR Art. 32. One answer. Four standards. That is not a shortcut — that is what a mature account management process actually looks like when described completely.
Use a collision-free ID scheme from the start.
This is a technical detail that pays significant dividends. Cross-standard questions should use domain-based prefixes that do not clash with any standard’s own naming: G- for Governance, A- for Access Control, INC- for Incident Response (not IR-, which collides with the NIST IR family), BCP- for Business Continuity, CFG- for Configuration Management (not CM-, which collides with NIST CM), CRY- for Cryptography, and so on.
NIST-specific questions — those covering Moderate baseline controls not addressed by any cross-standard question — should use a clearly distinct scheme: NIST-{family}-{sequence}, for example NIST-AC-07 for AC-7, NIST-PE-04 for PE-13. This makes the source of every question unambiguous and allows you to filter programmatically by standard without collision.
The Master tab is the only place answers live.
Every auditor view — ISO 27001 tab, ISO 42001 tab, NIST tab, GDPR tab — is a filtered subset of the Master, not an independent document. When the answer to a question changes, you update it once in the Master. The filter propagates to all auditor views automatically. If you find yourself maintaining two versions of an answer, your architecture has a flaw.
Add a Question Source column.
This single column distinguishes between cross-standard questions (one question, many standards) and NIST-specific questions (one control, one question). It tells any auditor looking at the sheet exactly what they are looking at and why the question exists. It also tells your team where to invest effort — cross-standard questions with a “★ Shared” marker satisfy three or more frameworks simultaneously and should be answered first.
What the Numbers Look Like in Practice
When we implemented this at client, the numbers clarified the approach nicely.
We ended up with 213 total questions in the Master: 104 cross-standard questions covering all 18 operational domains, and 109 NIST-specific questions covering NIST Moderate baseline controls that needed dedicated coverage. The NIST auditor view contains 212 questions — covering 235 distinct NIST controls — all filtered directly from the Master. The ISO 27001 view contains 209 questions. The GDPR view contains 206. The ISO 42001 view contains 138, reflecting that ISO 42001’s scope is intentionally narrower.
Of the 213 total questions, 56 are marked as shared controls — meaning a single answer to that question satisfies three or more standards simultaneously. These 56 questions are the highest-leverage evidence collection effort in your entire audit programme. Answer them well and you have satisfied the core control requirements of all four frameworks for the most critical domains: risk management, access control, encryption, incident response, supplier management, data protection, logging, and business continuity.
Before this restructure, we had a v3 workbook with 104 questions in the Master and 187 in a standalone NIST tab with zero structural connection between them. The root cause was that the NIST tab had been built as a separate catalog with NIST family-based IDs that clashed with our domain IDs, making cross-referencing impossible. This is a common mistake and worth naming explicitly: a NIST tab that cannot be proven to be a filtered view of the Master is not a single source of truth — it is a second source of truth, which is the same as no single source of truth at all.
The Columns That Make It Work
A Master Questionnaire has a specific anatomy. Every row needs:
Q-ID — unique, collision-free identifier following your scheme.
Domain — the operational domain, not the standard’s chapter.
Audit Question — written to satisfy all applicable standards simultaneously, framed around your actual controls and evidence.
Audit Type — Document Review, Technical Review, Interview, Sample, or combinations. This tells both your team and the auditor what kind of evidence the question expects.
ISO 27001:2022 reference — official Annex A control IDs (A.5.1 through A.8.34) and Clause references (Cl.4 through Cl.10). Not approximated — exact.
ISO 42001:2023 reference — official Annex A control IDs (A.2.2 through A.10.4) and Clause references. ISO 42001 Annex A objectives (A.x.1 entries) are not controls — the controls begin at A.x.2. This distinction matters when an ISO 42001 auditor checks your SoA.
NIST SP 800-53 Rev 5 reference — official control IDs with enhancement numbers. AC-2(1) is a different control from AC-2. A Moderate baseline assessment distinguishes between them. If your questionnaire collapses AC-2 and all its enhancements into a single cell without specifying which enhancements apply, your NIST assessor will push back.
GDPR reference — specific Article numbers at sub-article precision. Art. 5(1)(c) is different from Art. 5(1)(e). Art. 28(3) specifies the mandatory clauses in a DPA. Approximated references like “Art. 32 generally” are insufficient for a DPO-level review.
Answer column — blank, awaiting your response. This is the most important column in the workbook. It is where your security reality meets the standards’ requirements.
Status — a dropdown: Implemented, Partial, Not Implemented, N/A, Not Tested. The Partial status is particularly important — it tells auditors and management exactly where gaps exist without overstating or understating compliance.
Evidence / Document Reference — the policy name, version, section, screenshot, log excerpt, or configuration that proves the answer. This column is pre-filled with hints when you build the questionnaire (e.g., “Access Control Policy v1.3; 90-day review evidence; LastPass configuration”) and updated with actual references during audit preparation.
Question Owner — the individual responsible for providing the answer and evidence. Compliance does not happen in a CISO’s office alone. Owners span IT, HR, Legal, DevOps, the AI Officer, and the DPO.
Auditor Notes — reserved for the auditor. Your team does not pre-fill this column. It is the auditor’s workspace during the actual audit session.
Shared Control flag — a star marker for questions satisfying three or more standards. Your audit preparation team should complete all starred questions first. They represent the core of your compliance posture across every framework.
The Audit Session Experience
Here is what this looks like in practice when you sit down with an auditor.
Your ISO 27001 auditor receives the ISO 27001 filtered view tab. They see 209 questions, each with official Annex A or Clause references, your pre-populated answer, a status, and an evidence reference. They work through the Auditor Notes column adding their observations. They do not need to navigate the NIST questions or the AI governance section unless a control overlaps.
Your NIST assessor receives the NIST view tab: 212 questions covering 235 controls across all 20 families from AC through SR. Both cross-standard questions (where your Access Control Policy satisfies AC-1, AC-2, AC-3 simultaneously) and NIST-specific questions (AC-7 lockout thresholds, AC-11 device lock, SC-15 collaborative device controls) are visible, with the Question Source column clearly labeling each type.
Your DPO or privacy auditor receives the GDPR view: 206 questions covering Articles 5 through 83, with cross-references to the ISO 27001 and ISO 42001 controls that satisfy the same requirement. The RoPA question, the DPIA question, the data subject rights process question, the breach notification procedure — all answered once in the Master, surfaced here for the privacy auditor’s review.
What none of these auditors receive is a contradictory answer. Because there is only one answer. There is only one Master.
The AI Governance Layer
ISO 42001:2023 deserves specific attention because it is the newest of the four standards and the one most organizations are building from scratch rather than extending from existing programs.
The standard requires several things that have no direct analog in ISO 27001 or NIST. AI System Impact Assessments (AISIAs) are mandatory for every AI system in scope — a structured analysis of potential impacts on individuals, groups, and society, resulting in a Low, Medium, or High impact classification. This feeds directly into how much human oversight, transparency, and testing is required for each system. Your AI governance questions need to cover this lifecycle: system registration, AISIA, responsible design principles (A.6.1.3), verification and validation testing (A.6.2.4), controlled deployment (A.6.2.5), monitoring (A.8.5), and AI-specific incident management (A.8.4).
The AI data governance controls — A.7.2 through A.7.6 covering data quality, provenance, and preparation — have meaningful overlap with GDPR’s data minimisation (Art. 5(1)(c)), purpose limitation (Art. 5(1)(b)), and privacy by design (Art. 25) requirements. A single well-written question about AI data governance can cover all of these simultaneously, but only if you know both standards well enough to write it that way.
The EU AI Act adds a classification layer that sits above ISO 42001 rather than within it: your AI systems need to be assessed against the Act’s risk tiers (prohibited, high-risk Annex III, limited risk, minimal risk) with resulting compliance obligations. This is an AIX-domain question in the Master with no NIST equivalent — which is fine, because not every question needs to satisfy all four standards. The single source of truth principle does not mean every question covers every standard; it means every answer lives in one place.
Five Principles to Build By
If I were starting this process from scratch at a new organization, I would anchor on five principles from day one.
Official control IDs only. Approximated references create ambiguity that auditors exploit. If your ISO 27001 reference says “A.5 generally” instead of “A.5.15; A.5.16; A.5.18,” a thorough auditor will ask which specific controls you are claiming coverage for and you will have to reconstruct the mapping under pressure. Use the exact IDs from the published standards. ISO 27001:2022 Annex A runs from A.5.1 to A.8.34. NIST 800-53 Rev 5 AC-2(1) is a separate control from AC-2. These distinctions are in the standards for a reason.
Full coverage, not sampling. A Moderate NIST baseline assessment covers approximately 235 controls. An ISO 27001 audit covers all 93 Annex A controls. Sampling — picking representative controls from each family — may satisfy a checkbox exercise but it will not satisfy a thorough assessor and it will not actually tell you where your gaps are. The discipline of building complete coverage is also the discipline of discovering what you do not have implemented yet.
One answer, not four. If you catch yourself writing the same answer in two different tabs, your architecture is broken. Fix the architecture, not the duplicate. The structural constraint — all auditor views are filtered subsets of the Master — should make duplication physically impossible.
Gaps are information, not failure. The Partial and Not Implemented status options are not admissions of guilt — they are the output of an honest audit programme. A questionnaire where everything is marked Implemented before an auditor has looked at it is not a compliance programme; it is a liability. Real compliance posture requires knowing where you stand, including the uncomfortable parts.
The questionnaire is a living document, not a pre-audit scramble. The most valuable thing a Master Questionnaire does is shift compliance from a periodic event to a continuous state. When your IR procedure changes, you update the INC-01 answer. When you onboard a new AI service provider, you update the AIX-09 answer and the SUP-03 answer. The questionnaire should be reviewed quarterly, updated continuously, and owned by named individuals — not assembled in the three weeks before an auditor arrives.
A Note on AI-Assisted Compliance
One of the most significant changes in compliance practice over the last two years is the ability to use AI tools to populate questionnaire answers from an organization’s existing knowledge base — policies, procedures, security documentation, vendor assessments, architecture documents.
This does not replace human judgment. The Answer column in a Master Questionnaire still requires a human to verify accuracy, attach actual evidence references, and set a status they are willing to defend in an audit. But it dramatically compresses the time between “questionnaire template built” and “questionnaire ready for auditor review.”
At ShareVault, where our knowledge base includes our Security Policy, Access Control Policy, AI Management Policy, Incident Response Procedure, Risk Assessment Procedure, Privacy Policy, and Security & Availability documentation, an AI tool can populate an initial draft of most answers from these sources and flag which questions have insufficient documentation to answer — which is itself valuable information.
The key discipline is the same as for all AI-assisted work: the human remains accountable for the output. The AI drafts; the owner reviews, corrects, and signs off. The auditor evaluates the answer, not the method used to produce it.
Where to Start
If you are managing compliance across multiple standards and you recognize the structural problems described here, the path forward is straightforward even if the work is substantial.
Start with a gap analysis of what you currently have. Count your actual questions per standard. Map each one to the official control ID it is claiming to satisfy. Find the NIST families you have not covered at all (typically MA, MP, PE, PL, and SR are the most common gaps). Identify whether your auditor view tabs are provably filtered subsets of a master, or independent catalogs that happen to cover some of the same ground.
Then rebuild the Master with the architecture described above. It takes time to write 213 questions with precise official references. But you write them once. After that, every audit, every evidence collection cycle, and every questionnaire from a customer or prospect draws from the same source.
That is the value of a single source of truth. Not that compliance becomes easy — but that every effort you invest in it compounds instead of fragmenting.
The client team holds ISO 27001:2022 certification (SHA-27K-PRI) and ISO 42001:2023 certification (SHA-AIMS-20260129), maintains NIST SP 800-53 Rev 5 Moderate baseline verification, and operates under GDPR as both a data controller and processor for European customers. The Master Audit Questionnaire described in this article was built through iterative refinement of our own internal compliance programme.
Data breach notification requirements are complex in the US, with various federal and state laws containing different requirements for when security incidents must be disclosed.
Some even have substantially different definitions for what a ‘data breach’ or ‘personal data’ is.
As such, it can be hard to know whether you need to report an incident, let alone how you should go about it.
We address these issues in this blog, bringing some much-needed clarity to the subject.
State laws on data breach notification
There is no single set of data protection laws in the U.S., with the rules instead comprised of a patchwork of industry-specific federal laws and state legislation.
To complicate matters further, several states have created new laws in recent years to bolster data protection requirements. For instance, New York has created the SHIELD Act, while Colorado and California have both created data privacy legislation.
Elsewhere, the U.S. government is attempting to unify data protection requirements with its National Cybersecurity Strategy.
The decision to revise data protection laws follows the introduction of the EU GDPR (General Data Protection Regulation) in 2018, which radically shifted organizations’ requirements.
Organizations in the U.S. that process EU residents’ personal data are required to comply with the GDPR, and those that conduct business across state lines will face similar compliance challenges.
The GDPR is particularly important here, because many organizations in the U.S. assume that it only applies in the EU. However, its requirements apply to any organization that processes EU residents’ personal data, which is particularly common for organizations that have an online presence.
GDPR compliance is also helpful for managing patchwork of U.S. data protection legislations. Its requirements are far stricter than any domestic laws, so achieving GDPR compliance will cover you for a range of other requirements.
This free guide explains how and when the GDPR applies in the U.S. and the steps you can take to ensure your organization meets its transatlantic data processing practices.
You’ll also learn about the Regulation’s core principles and data subject rights, and the benefits of GDPR compliance.
We also provide tips on how to write your data privacy notice and give you tips on how to further your understanding of its compliance requirements.
Your data is an asset. Safeguarding it will help you comply with data protection laws and allow your business to thrive
A global leader in privacy guidance, audits, tools, training and software
IT Governance is a market leader in data privacy and cyber security solutions. Their broad suite of offerings is one of the most comprehensive in the world.
ITG affordable solutions have assisted numerous individuals and organizations in understanding the tangible aspects of data privacy. With substantial legal and technical proficiency, coupled with a 15-year history in cybersecurity risk management, ITG customers have complete confidence in entrusting us with their needs.
Speed up your compliance initiatives for GDPR, CPRA, and other regulations ISO 27701 by utilizing ITG collection of top-performing Tools, Templates and eBooks.
For a limited time only, ITG is offering bestselling implementation guides free with each toolkit purchase.*
All the pre-written policies and procedures you’ll ever need.
Written by our expert team of in-house consultants, who have been delivering cyber security and data privacy consultancy for years.
Reviewed throughout the year to ensure you’re always working from the most up-to-date documentation, in line with the latest guidance and standard revisions, including free upgrades.
Accessible on our Cloud-based platform, DocumentKits, so you can collaborate with team members, viewing, editing and downloading documents any time, anywhere.
French data protection authority says Google Analytics is in violation of GDPR
The French national data protection authority, CNIL, issued a formal notice to managers of an unnamed local website today arguing that its use of Google Analytics is in violation of the European Union’s General Data Protection Regulation, following a similar decision by Austria last month.
The root of the issue stems from the website’s use of Google Analytics, which functions as a tool for managers to track content performance and page visits. CNIL said the tool’s use and transfer of personal data to the U.S. fails to abide by landmark European regulations because the U.S. was deemed to not have equivalent privacy protections.
European regulators including CNIL have been investigating such complaints over the last two years, following a decision by the EU’s top court that invalidated the U.S.’s “Privacy Shield” agreement on data transfers. NOYB, the European Center for Digital Rights, reported 101 complaints in 27 member states of the EU and 3 states in the European Economic Area against data controllers who conduct the transatlantic transfers.
Privacy Shield, which went into effect in August of 2016, was a “self-certification mechanism for companies established in the United States of America,” according to CNIL.
Originally, the Privacy Shield was considered by the European Commission to be a sufficient safeguard for transferring personal data from European entities to the United States. However, in 2020 the adequacy decision was reversed due to no longer meeting standards.
An equivalency test was used to compare European and U.S. regulations which immediately established the U.S.’s failure to protect the data of non-U.S. citizens. European citizens would remain unaware that their data is being used and how it is being used, and they cannot be compensated for any misuse of data, CNIL found.
CNIL concluded that Google Analytics does not provide adequate supervision or regulation, and the risks for French users of the tool are too great.
“Indeed, if Google has adopted additional measures to regulate data transfers within the framework of the Google Analytics functionality, these are not sufficient to exclude the possibility of access by American intelligence services to this data,” CNIL said.
The unnamed site manager has been given a month to update its operations to be in compliance with GDPR. If the tool cannot meet regulations, CNIL suggests transitioning away from the current state of Google Analytics and replacing it with a different tool that does not transmit the data.
The privacy watchdog does not call for a ban of Google Analytics, but rather suggests revisions that follow the guidelines. “Concerning the audience measurement and analysis services of a website, the CNIL recommends that these tools be used only to produce anonymous statistical data, thus allowing an exemption from consent if the data controller ensures that there are no illegal transfers,” the watchdog said.
GDPR compliance got even more complicated this summer when the CJEU (European Court of Justice) ruled the EU–US Privacy Shield invalid.
Organizations that had relied on the framework for transatlantic data transfers have been scrambling for a solution – with even some multinationals unsure how to proceed.
If you’re among those trying to understand how the ruling affects your data transfer processes, then ITGP updated books can help.
EU General Data Protection Regulation (GDPR) – An implementation and compliance guide
This comprehensive guide covers:
DPO (data protection officer) requirements, including which organizations need a DPO and what DPOs do;
When organizations must conduct DPIAs (data protection impact assessments);
GDPR implementation FAQs;
Guidance on how to create data protection processes that are in line with best practices; and
ISO/IEC 27701 is the international standard that serves as an extension to an ISO 27001/ ISO 27002 #ISMS (information security management system). It provides guidelines for implementing, maintaining, and continually improving a #PIMS (privacy information management system).
Develop a privacy information management system as an extension to your ISO 27001-conformant ISMS with ISO/IEC 27701. Supports GDPR compliance.
SECURITY TECHNIQUES — EXTENSION TO ISO/IEC 27001 AND ISO/IEC 27002 FOR PRIVACY INFORMATION MANAGEMENT SYSTEM #PIMS
Key features:
* The Standard includes mapping to the GDPR, ISO/IEC 29100, ISO/IEC 27018, and ISO/IEC 29151
* Integrates with other management system standards, including the information security standard, ISO/IEC 27001
* Provides PIMS-specific guidance for ISO/IEC 27002
* Specifies requirements and provides guidance for establishing, implementing, maintaining, and continually improving a PIMS
* Supports compliance with the GDPR and DPA 2018
* Provides guidance for data controllers and processors responsible for processing personal data
ISO 27701 Gap Analysis Tool
Achieve full compliance with ISO 27701:2019
The ISO 27701 Gap Analysis Tool has been created to help organizations identify whether they are meeting the requirements of the Standard and where they are falling short. Note that this tool assumes that you have a complete and functioning ISO 27001:2013 ISMS (information security management system).
It helps organizations prioritise work areas in order to expand an existing ISMS to take account of privacy. It also gives organizations direction, helping project managers identify where to start.
What does the tool do?
Contains a set of sample audit questions
Lists all ISO 27701:2019 requirements, identifying where documentation is mandatory for compliance
Provides a clear, colour-coded report on the state of compliance
The executive summary displays the results of compliance in a clear table so that you can report on your results and measure the closure of gaps.
The tool is designed to work in any Microsoft environment. It does not need to be installed like software, and it does not depend on complex databases; it relies on human involvement.
ISO 27701 The New Privacy Extension for ISO 27001
httpv://www.youtube.com/watch?v=-NUfTDXlv30
Quick Guide to ISO/IEC 27701 – The Newest Privacy Information Standard
httpv://www.youtube.com/watch?v=ilw4UmMSlU4
Big news is coming when NIST takes the wraps off a new privacy framework. Thanks to the General Data Privacy Regulation (GDPR) of the European Union, which took full effect in May 2018, privacy is at center stage worldwide. Penalties are being meted out for violations, and organizations of all kinds need to understand and comply with the law. In addition, the California Consumer Privacy Act (CCPA) was enacted in June 2018, with many other states working on similar bills.
Any data you look at shows that the scale of ‘Internet evil’ increases every year. The economic impact of cyber crime now exceeds $1.1 million per minute. This is a major corporate risk, irrespective of organisational size, and cyber insurance is an inadequate response – insurers will not pay out where you have been negligent.
The EU’s GDPR (General Data Protection Regulation) makes the tests for negligence pretty clear: absence of accountability, insufficient corporate governance and countermeasures that do not adequately respond to the frequency and virulence of today’s attacks.
In an environment where four potentially vulnerable web components are discovered every minute, an annual penetration test is only slightly better than not bothering at all. We run penetration tests about once a month; you should be doing them at least quarterly. However, even if you do this, you need to recognise that purely technical responses have limited benefits. Staff are the weakest of your links, particularly as phishing and ransomware attacks get smarter every day. And your supply chain may increasingly be your attackers’ fastest route into what passes for your secure environment. Staff awareness training only every year or two would be desperately short-sighted.
We’re going to see more and more organisations reporting data breaches – it’s now an offence to not report one, and you can be punished with significant fines. The costs don’t stop there. After you report a breach, and undergo investigation, fines and reputational damage, you still have to spend the money to get secure. It therefore probably works out less expensive in the long run to make comprehensive cyber security investments before you are breached (assuming that you haven’t already been breached, and you just don’t know it yet).
The GDPR will replace these with a pan-European regulatory framework effective from 25 May 2018. The GDPR applies to all EU organizations – whether commercial business or public authority – that collect, store or process the personal data (PII) of EU individuals.
Organizations based outside the EU that monitor or offer goods and services to individuals in the EU will have to observe the new European rules and adhere to the same level of protection of personal data. This potentially includes organizations everywhere in the world, regardless of how difficult it may be to enforce the Regulation. Compliance consultant must know the following 9 tenants of the GDPR.
Supervisory Authority – A one-stop shop provision means that organizations will only have to deal with a single supervisory authority, not one for each of the EU’s 28 member states, making it simpler and cheaper for companies to do business in the EU.
Breach Disclosure – Organizations must disclose and document the causes of breaches, effects of breaches, and actions taken to address them.
Processor must be able to provide “sufficient guarantees to implement appropriate technical and organizational measures” to ensure that processing will comply with the GDPR and that data subjects’ rights are protected. This requirement flows down the supply chain, so a processor cannot subcontract work to a second processor without the controller’s explicit authorization. If requested by subject you must cease processing and using his or her data for some limited period of time.
Data Consent – The Regulation imposes stricter requirements on obtaining valid consent from individuals to justify the processing of their personal data. Consent must be “freely given, specific, informed and unambiguous indication of the individual’s wishes”. The organization must also keep records so it can demonstrate that consent has been given by the relevant individual. Data can only be used for the purposes that data subject originally explicitly consented. You must obtain and document consent for only one specific purpose at a time.
Right to be forgotten – Individuals have a right to require the data controller to erase all personal data held about them in certain circumstances, such as where the data is no longer necessary for the purposes for which it was collected. If requested by subject, you must erase their data on premises, in apps and on devices.
Data portability – Individuals will have the right to transfer personal data from one data controller to another where processing is based on consent or necessity for the performance of a contract, or where processing is carried out by automated means
Documentation – The Regulation requires quite a bit of documentation. In addition to the explicit and implicit requirements for specific records (especially including proof of consent from data subjects), you should also ensure that you have documented how you comply with the GDPR so that you have some evidence to support your claims if the supervisory authority has any cause to investigate.
Fines – Major noncompliance of the law will be punishable by fines of up to either 4% or €20 million of group annual worldwide turnover.
Data protection by design – Organization must ensure data security and data privacy across cloud and endpoints as well as design their system and processes that protects from unauthorized data access and malware. Specifically, organizations must take appropriate technical and organizational measures before data processing begin to ensure that it meets the requirements of the Regulation. Data privacy risks must be properly assessed, and controllers may use adherence to approved codes of conduct or management system certifications, such as ISO 27001, to demonstrate their compliance.
How to improve information security under the GDPR
Although many businesses understand the importance of implementing the right procedures for detection, report and investigate a data breach, but not many are aware of how to go about this effectively, especially during implementation phase.
Seven steps that can help you prevent a data breach:
Find out where your personal information resides and prioritize your data.
Identify all the risks that could cause a breach of your personal data.
Apply the most appropriate measures (controls) to mitigate those risks.
Implement the necessary policies and procedures to support the controls.
Conduct regular tests and audits to make sure the controls are working as intended.
Review, report and update your plans regularly.
Implement comprehensive and robust ISMS.
ISO 27001, the international information security standard, can help you achieve all of the above and protect all your other confidential company information, too. To achieve GDPR compliance, feel free to contact us for more detail on implementation.
As part of an EU General Data Protection Regulation (GDPR) compliance project, organisations will need to map their data and information flows in order to assess their privacy risks. This is also an essential first step for completing a data protection impact assessment (DPIA), which is mandatory for certain types of processing.
The key elements of data mapping
To effectively map your data, you need to understand the information flow, describe it and identify its key elements.
1. Understand the information flow
An information flow is a transfer of information from one location to another, for example:
From inside to outside the European Union; or
From suppliers and sub-suppliers through to customers.
2. Describe the information flow
Walk through the information lifecycle to identify unforeseen or unintended uses of data. This also helps to minimise what data is collected.
Make sure the people who will be using the information are consulted on the practical implications.
Consider the potential future uses of the information collected, even if it is not immediately necessary.
3. Identify its key elements
Data items
What kind of data is being processed (name, email, address, etc.) and what category does it fall into (health data, criminal records, location data, etc.)?
Formats
In what format do you store data (hardcopy, digital, database, bring your own device, mobile phones, etc.)?
Transfer method
How do you collect data (post, telephone, social media) and how do you share it internally (within your organisation) and externally (with third parties)?
Location
What locations are involved within the data flow (offices, the Cloud, third parties, etc.)?
Accountability
Who is accountable for the personal data? Often this changes as the data moves throughout the organisation.
Access
Who has access to the data in question?
The key challenges of data mapping
Identifying personal data Personal data can reside in a number of locations and be stored in a number of formats, such as paper, electronic and audio. Your first challenge is deciding what information you need to record and in what format.
Identifying appropriate technical and organizational safeguards The second challenge is likely to be identifying the appropriate technology – and the policy and procedures for its use – to protect information while also determining who controls access to it.
Understanding legal and regulatory obligations Your final challenge is determining what your organisation’s legal and regulatory obligations are. As well as the GDPR, this can include other compliance standards, such as the Payment Card Industry Data Security Standard (PCI DSS) and ISO 27001.Once you’ve completed these three challenges, you’ll be in a position to move forward, gaining the trust and confidence of your key stakeholders.
Data flow mapping
To help you gather the above information and consolidate it into one area, Vigilant Software, a subsidiary of IT Governance, has developed a data flow mapping tool with a specific focus on the GDPR.
