Crosswalk pair
GDPR and PIPEDA, control by control
22 canonical controls in Keel’s library satisfy clauses of both GDPR and PIPEDA. Implement each once, attach the evidence once, and it counts toward each standard. The overlap is the work you don’t repeat.
The overlap
What the two libraries have in common
Every figure here counts canonical controls in Keel’s library, not clauses of either standard. Each standard’s own authored count is on its framework page.
22
Controls that satisfy both
Canonical controls that crosswalk to at least one clause of each.
50
In Keel’s library for GDPR
44% of them also map to PIPEDA.
30
In Keel’s library for PIPEDA
73% of them also map to GDPR.
93
Evidence artifacts expected
Across the shared controls, from Keel’s evidence guidance. Gathered once.
The mapping
Controls that satisfy both
Each row is one control in Keel’s library and the clauses it answers on each side. Do the work once; both columns are then evidenced by the same artifacts.
| Canonical control | GDPR clauses | PIPEDA clauses |
|---|---|---|
| Governance & Risk | ||
| Data protection accountability program The organization can show, not merely assert, that its handling of personal data meets the principles it is bound by: for each one - lawfulness, fairness and transparency; purpose limitation; data minimization; accuracy; storage limitation; and integrity and confidentiality - it names the measure that gives effect to it and the record that would demonstrate it to somebody who asked, so the answer to "prove it" is a document rather than a description. The measures are technical and organizational together, and how far they go is decided against the nature, scope, context and purposes of the processing and against the likelihood and severity of the risk it poses to the people whose data it is - a low-risk mailing list and a large-scale profiling operation are not held to the same set, and the reasoning that put a given activity in one place rather than the other is written down. Accountability has a named owner, a documented program of work, and one place the evidence lives. The whole set is reviewed and updated where the review shows it is needed: when the processing changes, when a new risk appears, when an incident or an audit exposes a weakness, and on a stated cadence in the absence of any of those - so what is in place tracks the processing rather than the date somebody last wrote it down. | Art.5(2), Art.24(1) | 4.1.4 |
| Information security policy A board-approved policy set covering information security and the handling of personal data, sized to the scale of the organization and the type of activities it actually carries out, reviewed at least annually and communicated to the workforce. The policy set states the direction the organization is taking on information security - what it commits to, and what it requires of everyone doing work for it - so it sets where the program is going rather than only recording what it already does. One or more named individuals are designated to coordinate the program the policies describe - the person in charge of it, named rather than implied, with the designation recorded in writing, made known to the people who need it and kept current as roles change - so there is someone who answers for the policies being carried out and not only for their being published. How far the policies go, and how far the measures they require go, is judged against four things together: the organization’s size, complexity and capabilities; its technical infrastructure and the security capabilities of its hardware and software; what the measures cost; and how likely the risks they address are and how much damage they would do. A policy may be changed at any time, provided the change is documented and is actually put into effect rather than only written down. Review is triggered by events as well as by the calendar: the policy set is revisited and updated when the requirements the organization is under change, when the threat picture changes, when the technology it depends on changes, and when its mission changes - and it is enforced rather than only issued, with non-compliance handled through the stated route instead of tolerated. | Art.24(2) | 4.1.4, 4.7 |
| Access Control | ||
| Access control policy Rules for granting, reviewing, and revoking access to systems and data based on business need and least privilege; anyone who works with sensitive data, or in a place from which it can be reached, is individually authorized for that work or supervised while doing it; and a documented emergency route exists to obtain the data when the normal access path is unavailable, with every use of that route recorded and reviewed afterwards. The rules also settle the opposite question: which actions, if any, a person may take on a system without identifying or authenticating themselves at all. Those actions are identified rather than left as whatever the system happens to permit, they are limited to what the organization’s business actually requires, and each one is documented in the system’s security plan together with the reasoning that justifies it, so an unauthenticated path is a decision somebody made and can be asked about. The rules are enforced by access control lists set on the data itself, not only by what an application chooses to show: permissions on local and remote file systems, on databases and inside applications are configured to the holder’s need to know, so information a role has no business reading is unreachable rather than merely unadvertised. What an authorized user may DO is limited on the same terms as what they may read: the types of transaction and function each role is permitted to execute are decided in advance and enforced by the system, so holding access to an application does not carry the right to run every operation inside it, and an action outside the permitted set is refused rather than merely unadvertised in the interface. Enforcement is centralized wherever the systems support it - access decisions for enterprise assets are made by a single directory service or single sign-on provider rather than by each system keeping its own list - and the systems that make those decisions are themselves known: an inventory of the organization’s authentication and authorization systems is maintained, including those run by a service provider on its behalf, and reviewed on a defined cadence. | Art.32(1) | 4.7.1, 4.7.3 |
| Data Protection & Privacy | ||
| Authorized disclosure of personal information Personal information leaves the organization only for a purpose it has disclosed and on the consent or other authority it obtained, and that is checked before the disclosure rather than reconstructed after it. Standing disclosures - a processor, a partner, an integration a customer has switched on - are approved in advance, listed, and tied to the purpose and the authority that permits them, and the list is reviewed rather than left to accumulate. A one-off request, including one from a law-enforcement or government body, goes to a named role who establishes what is being asked for, on what authority, and how much of it is genuinely required, and who releases the minimum that answers it; where the organization is permitted to tell the person concerned, it does. A demand that arrives as a judgment of a court or a decision of an administrative authority in another country is not treated as compelling disclosure on its face: it is recognized or enforced only where it rests on an international agreement in force - a mutual legal assistance treaty or equivalent - between that country and the jurisdiction the organization answers to, and where it does not, the organization looks for a separate lawful ground for the transfer instead of complying because a document looked official, takes advice before responding, and records what it decided and why. Everyone who can release personal information knows this is the only route, and a release outside it is handled as an incident rather than as an exception to be tidied up. | Art.48 | 4.5, 7(3) |
| Choice & consent for personal information Before personal information is collected, the person it is about is told what choices they have over it - what they may decline, what they can turn off later, and what declining will mean for the service they receive - in words that state the consequence rather than implying it. The choice is captured as a positive act and recorded together with what was presented, when, and by which route, so the organization can show later what a person actually agreed to rather than what today’s form says. Where the information is of a kind that needs explicit agreement, that agreement is asked for separately and obtained before the collection happens, not bundled into a general acceptance of terms. Where agreement is sought inside a written declaration that also covers other matters - terms of service, an employment contract, an order form - the request for it is presented so that it clearly stands out from the rest, in a form that is intelligible and easy to get at, in clear and plain language, rather than reading as one clause among many. Agreement is asked for only where the person is genuinely free to refuse: the organization does not make a service or a contract conditional on agreeing to processing that the service or contract does not actually need, and where it depends on agreement it can say what it is needed for. Before the person agrees, they are told that they may take the agreement back at any time and that doing so does not make what was already done unlawful. A person can change or withdraw a choice by a route no harder than the one that gave it; the change takes effect in the systems that act on it rather than only in the record of it; and the record is added to rather than overwritten, so the history of what was agreed survives. | Art.7(1), Art.7(2), Art.7(3), Art.7(4) | 4.3, 4.3.1, 4.3.3, 4.3.6, 4.3.7, 4.3.8, 6.1 |
| Data classification & handling Information is classified and handled per its sensitivity, with rules for labeling and protection - including the everyday handling rules that stop it being seen, overheard or picked up by people with no business reading it, so exposure that happens incidentally alongside legitimate work is limited rather than accepted. The handling rules are written to cover disclosure that nobody intended as much as disclosure that somebody chose, they say what an unauthorized disclosure is against the organization’s own privacy and confidentiality rules rather than leaving that to judgment in the moment, and they reach every medium the information travels in - spoken, on paper, on a screen and in a system - because the incidental exposure they exist to limit does not respect the boundary between an administrative, a physical and a technical safeguard. Labeling is the procedure that makes the classification visible, and it is defined rather than left to habit: there is a label for each level of the scheme, a rule for how the label is applied in each form the information takes - a document, an email, a file, a database field, a screen, a report, a piece of removable media, a printed page - and, where a system supports it, the label is carried in metadata so it can be acted on automatically rather than only read. The person who creates or receives the information applies the label at that point rather than later, the label travels with the information when it is copied, extracted, exported or transferred so a copy does not arrive unclassified, and information derived from or aggregated out of classified sources is labeled for what the combination is worth rather than for what the least sensitive input was. Where a label would itself disclose something, an agreed alternative is used and recorded, and the procedure covers what to do when unlabeled information is found. On storage media the marking carries more than the level: it states the distribution limitations that apply and any handling caveats that travel with the contents, so somebody who picks the item up knows what they may do with it without having to ask. Where the organization exempts a class of media from marking because it never leaves a controlled area, that exemption is defined and recorded as a decision rather than practiced as an omission. Underneath the scheme sits a documented DATA MANAGEMENT PROCESS that the classification and the handling rules are derived from: it states how sensitivity is decided, who owns each category of data, how each category is handled, the retention limits that apply to it and what disposal it requires, and it is reviewed and updated on a defined cadence and whenever a change to the organization would alter it. That process is also what the DATA FLOWS are documented against - where each category of information originates, which systems and processes it moves between, and where it crosses out to a service provider - recorded as documentation somebody maintains rather than reconstructed when a question is asked, and reviewed on the same cadence. | Art.5(1) | 4.3.4, 4.7.2 |
| Data retention & secure disposal Data is retained per policy and securely destroyed when no longer needed. Retention periods are set against the purpose the data was collected for and any legal or contractual obligation to keep it, recorded per category of data rather than left to whoever is looking at the record, and enforced when they run out - data goes because its period ended, not because somebody finally objected to keeping it. Destruction leaves it unrecoverable rather than merely removed from an index, and what was destroyed, when, by what method and on whose authority is recorded. The hardware and media that held it reach a defined final disposition at end of life, by a route the organization has decided in advance rather than by whatever happens to the box; and any media that stays in service is cleared of that data before it is reused, reassigned, or passed to anyone else. Disposal is not confined to data and media: the documentation, the tools and the system components the organization has defined as needing it are disposed of by techniques and methods it has approved in advance - so a decommissioned appliance, a retired build server, a set of network diagrams or a licensed utility leaves the organization by a route somebody chose, and the route is recorded on the same terms as a data destruction. A retention period has two ends and both are stated: the minimum the organization must keep the data for, and the maximum beyond which it may not be kept - so retention is bounded in the direction of keeping too long as well as of destroying too early. | Art.5(1) | 4.5, 4.5.2, 4.5.3, 4.7.5, 8(8) |
| Data subject request procedure & deadlines A written procedure governs what happens between a request about someone’s own personal data arriving and the answer going out, and it is owned by a named role rather than by whoever opened the inbox. The action taken is reported to the person without undue delay and in any event within one month of receiving the request. That month may be extended by two further months where the request is complex or where several have arrived together - but only if the person is told of the extension and the reason for it inside the first month, so an extension is a communication rather than a silence. Where the organization decides to take no action, it says so within that same month, gives the reasons, and tells the person that they may lodge a complaint with a supervisory authority and seek a judicial remedy, so a refusal always carries the route to challenge it. Information and action on a request are provided free of charge in the ordinary case. A request that is manifestly unfounded or excessive - a repetitive one is the usual example - may instead attract a reasonable fee based on the administrative cost of answering it, or be refused outright, but the reasoning that gives the request that character is written down before either step is taken, because the burden of demonstrating it sits with the organization and not with the person asking. Where the organization genuinely cannot identify the person from the data it holds, it tells them so where it is possible to do so, and explains that the access, rectification, erasure, restriction, notification and portability rights cannot be acted on unless they supply information that enables identification - rather than refusing without explanation, or manufacturing an identification it does not have. Where a request arrives electronically the answer goes back electronically unless the person asks otherwise. Every request is logged with the date it arrived, the deadline that applies to it, the decision, the date of the reply and who made it, so the clock is a tracked commitment rather than an intention. | Art.11(2), Art.12(3), Art.12(4), Art.12(5) | 8(1), 8(3), 8(4), 8(6), 8(7) |
| Encryption in transit & at rest Strong cryptography protects sensitive data in transit over public networks and at rest in storage. The mechanisms are chosen to do two things and are judged against both: prevent unauthorized disclosure of the information, and prevent or detect unauthorized change to it - in transit, so a message altered between sender and receiver is caught rather than delivered, and at rest, so a stored record cannot be modified undetectably by somebody with access to the storage but not to the key. Which information is protected at rest, and on which system components, is decided and recorded rather than left to whatever the platform encrypts by default. The scope named explicitly reaches the end-user device as well as the server: data held on laptops, desktops and other end-user devices that carry sensitive information is encrypted at the device or volume level, so a device that leaves the building is an object somebody lost rather than a disclosure. And data in transit is encrypted wherever it is sensitive, not only where it crosses a public network - a session between two internal systems is protected on the same terms when what it carries warrants it. Where a law, a regulation or a contract requires the cryptography to be VALIDATED rather than merely strong, the organization uses a cryptographic module that carries the validation that instrument names, and it confirms that validation against the specific module, version and operating mode actually deployed rather than inferring it from the product’s name - because a validated module run outside the configuration it was validated in is not a validated module, and the certificate that proves the point is held as evidence rather than assumed to exist. | Art.32(1) | 4.7, 4.7.1, 4.7.3 |
| Fulfilling an access request When someone asks for their personal data, what goes back is a copy of the data actually undergoing processing, assembled from the systems that hold it rather than from whichever one was easiest to export. Where the request arrives by electronic means the copy is provided in a commonly used electronic form, unless the person has asked for something else. The first copy is free; a reasonable fee based on administrative cost may be charged for further copies the same person asks for, and the basis of that fee is stated rather than improvised. Where any of the data has been transferred to another country or to an international organization, the response tells the person which appropriate safeguards protect that transfer, so a transfer disclosed in the abstract in a privacy notice is made concrete for their own data. Before anything is released it is reviewed so that providing it does not adversely affect the rights and freedoms of other people: personal data about somebody else, material a third party holds rights in, and content protected by an obligation of confidence are redacted or withheld, and the decision to withhold is recorded with its reason and the rest of the response is still provided - a third party in the file is not a reason to refuse the request. Who assembles a response, who reviews it before release, and how it is delivered securely to the person who asked are all fixed in advance rather than decided per request. | Art.15(2), Art.15(3), Art.15(4) | 4.9.1, 4.9.4, 10 |
| Information given when data is collected from the individual At the moment personal data is taken directly from a person, they are given a complete set of information about what is about to happen to it, in one place and in language they can follow. It identifies the organization and how to contact it, and its representative where it has one; gives the contact details of the data protection officer where one is designated; states each purpose the data is intended for and the legal ground relied on for each; states the legitimate interests pursued by the organization or by a third party wherever legitimate interests is that ground; names the recipients or the categories of recipient, if there are any; and, where the data is intended to go to another country or to an international organization, says so and says whether a formal adequacy decision covers the destination or which safeguards are relied on in its absence, together with how to obtain a copy of those safeguards or where they have been made available. Because fair and transparent processing needs more than that, the same notice also gives the period the data will be stored for or, where that cannot be stated, the criteria used to fix it; the rights to request access, rectification, erasure and restriction, to object, and to data portability; the right to withdraw consent at any time without affecting the lawfulness of what was done before the withdrawal, wherever consent is the ground; the right to lodge a complaint with a supervisory authority; whether providing the data is a statutory or contractual requirement or is necessary to enter into a contract, whether the person is obliged to provide it, and what the consequences of not providing it are; and the existence of any decision-making carried out solely by automated means, profiling included, with meaningful information about the logic involved and about the significance and envisaged consequences of it for that person. The notice is delivered at the point of collection rather than left somewhere to be found afterwards, and each version is dated and retained so the organization can show what a particular person was actually told. Where the data is later to be used for a purpose other than the one it was collected for, the person is told about that other purpose, together with the further information above that goes with it, before the new use starts rather than after. | Art.13(1), Art.13(2), Art.13(3) | 4.2.3, 4.3.2 |
| International transfers of personal data Every route by which personal data leaves the region - a hosting location, a support team, a subcontractor, a backup, a group company, a remote administrator with access from elsewhere - is identified and mapped before it is relied on, and each one is placed on a transfer mechanism that is written down. Onward transfers are inside the same discipline: where the recipient may pass the data on again, that further movement is covered too, and the whole chain is arranged so that the level of protection the law guarantees is not undermined by the last step in it. Where a formal adequacy decision covers the destination, the organization records which one and keeps it under review, because such decisions are amended and withdrawn. Where none does, the transfer proceeds only where the organization has provided appropriate safeguards and the people whose data it is retain enforceable rights and effective legal remedies. Which safeguard is being used is recorded per transfer, from those available without any supervisory authority authorization - a legally binding and enforceable instrument between public bodies, binding corporate rules, standard data protection clauses adopted by the Commission or adopted by a supervisory authority and approved by the Commission, or an approved code of conduct or certification mechanism coupled with binding and enforceable commitments by the recipient to apply the safeguards including as regards individuals’ rights - and the organization also knows which routes are NOT available without authorization: bespoke contractual clauses agreed with the recipient, and provisions inserted into administrative arrangements between public bodies, both of which require the competent supervisory authority to authorize them before the transfer proceeds. A clause set is not treated as a safeguard on signature alone: the organization assesses whether the law and practice of the destination actually let the clauses work, and applies supplementary measures where they do not. Only where neither adequacy nor a safeguard is available does the organization look to a derogation, and then narrowly and per transfer rather than as a standing basis - explicit consent given after the person has been informed of the risks that follow from the absence of adequacy and safeguards; necessity for a contract with the person or for pre-contractual steps at their request; necessity for a contract concluded in their interest with another party; important reasons of public interest; bringing or defending legal claims; vital interests where the person cannot consent; or a transfer from a public register, which may not involve the whole register or entire categories of the data in it and, where the register is open only to persons with a legitimate interest, may be made only at their request or to them as recipients. Where none of those applies and the transfer rests instead on the organization’s compelling legitimate interests, the stricter conditions are checked and met - the transfer is not repetitive, concerns only a limited number of people, is necessary for interests not overridden by theirs, and all the circumstances have been assessed and suitable safeguards provided on the strength of that assessment - the supervisory authority is informed of the transfer, the people affected are told about it and about the interests pursued in addition to the ordinary information they are owed, and the assessment and the safeguards are documented in the record of processing activities rather than in a memo nobody can find. | Art.44, Art.46(1), Art.46(2), Art.46(3), Art.49(1), Art.49(2), Art.49(6) | 4.1.3 |
| Lawful basis for processing Every processing activity has a lawful ground identified and recorded before it starts, chosen from the grounds the law makes available rather than assumed after the fact - the individual’s consent, necessity for a contract with them or for steps taken at their request before entering one, a legal obligation on the organization, someone’s vital interests, a task carried out in the public interest or under official authority, or legitimate interests pursued by the organization or by a third party. Where legitimate interests is the ground, the interest is stated, the processing is tested as actually necessary to it, and the interest is weighed against the interests, rights and freedoms of the people affected - with particular weight where any of them is a child - and that assessment is written down rather than reached in conversation; a public authority may not rely on legitimate interests at all for the processing it carries out in performing its tasks. Where consent or a contract is the ground, what makes it available is recorded too, so a later reader can see why the ground applies to this activity and not merely that somebody selected it. The ground is revisited when the activity changes, when the ground stops being available - consent withdrawn, a contract ended, an obligation repealed - and on the same cadence as the register of processing activities; an activity found to have no ground is stopped rather than allowed to run while the question is settled. Where personal data feeds an AI system - as training data, as tuning data, or as an input at inference - that use is treated as a processing activity in its own right and given its own recorded ground, rather than inheriting the ground recorded for the activity the data was first collected under. The rights the people concerned hold over that processing are routed into the same procedure that serves every other activity, so a request is not refused on the basis that the data has been absorbed into a model. | Art.6(1) | 5(3), 7(1), 7(2) |
| Personal data privacy A privacy notice the organization owns and dates tells the people whose personal data it holds - employees, customers, and anybody else it collects from - what is collected and where from, the purposes it is used for, how long it is kept, who it is disclosed to, what choices and rights they have and how to exercise them, and how employees are monitored at work. It is written in plain language, published where those people will find it, and revised and made available BEFORE a change in practice takes effect rather than after. Each request about that data - to see it or get a copy, to have it corrected, to have it erased, to restrict or object to a use - is logged when it arrives, the requester’s identity is checked, and it is decided and actioned inside the time the organization has committed to; what is provided is what was asked for, and a refusal is given with its reason rather than by silence. An accepted correction is applied to every copy the organization holds and passed on to the parties it has already disclosed that data to, so a correction does not stop at whichever system the request happened to arrive in. | Art.12(1), Art.12(2), Art.15(1), Art.16, Art.17(1), Art.21(1) | 4.2, 4.2.3 |
| Record of disclosures of personal information Every disclosure of personal information to a party outside the organization is recorded as it is made - the date, who received it, what was disclosed, the purpose, and the authority relied on - so the record is built while disclosures happen rather than reconstructed from memory once somebody asks. Disclosures that were not authorized are recorded in the same place, whether the organization detected one itself or was told of one by a recipient, a customer or a regulator, together with what went out, how it happened, and what was done about it - so an unauthorized disclosure is not invisible for having been unintended, and the two kinds can be answered together. On request, an individual is told what personal information the organization holds about them and who it has been disclosed to, drawn from that record and provided inside the time the organization has committed to; where a category of disclosure is left out of what is reported, that exclusion is stated in advance rather than decided request by request. The same record is what makes a downstream correction possible: where personal information is corrected, erased, or its processing restricted, that change is communicated to each recipient the information was disclosed to, so the parties acting on it are working from the corrected position rather than from what they were originally sent. Where communicating it would genuinely be impossible or take disproportionate effort, that conclusion is recorded against the entry with its reason rather than reached silently, and the individual is told which recipients received their information whenever they ask. | Art.19 | 4.9.3 |
| Record of processing activities (RoPA) A register of every activity in which the organization processes personal data, kept current as processing changes rather than assembled for an audit — each entry recording the purpose, the lawful basis relied on, the categories of individuals and of personal data, who the data is disclosed to, how long it is kept, any transfer outside the region with the safeguards relied on, and the security measures protecting it. The register is kept in writing, electronic form included, so it is a record that can be produced rather than knowledge held by whoever has been here longest. | Art.30(1), Art.30(3) | 4.2.1, 4.5.1 |
| Use limited to disclosed purposes Personal information is used only for the purposes that were disclosed and agreed to, and the limit is enforced where the use happens rather than stated only in a policy: datasets and systems carry the purpose the data was collected for, and a new use is checked against it before it begins. A use outside those purposes - a new analysis, a new feature, a new audience, training a model, a secondary use by another team - is treated as a change that requires either a fresh disclosure and a fresh choice, or a recorded decision that it is compatible with the original purpose together with the reasoning for that. Where the new purpose rests on neither a fresh consent nor a law that provides for it, the compatibility decision is made against stated factors rather than asserted: any link between the purpose the data was collected for and the intended new one; the context in which it was collected, and in particular what the people concerned would reasonably expect given their relationship with the organization; the nature of the data, and whether it includes the categories that carry extra protection or data about criminal convictions and offenses; the possible consequences of the intended use for those people; and the safeguards that would apply to it, which may include encryption or pseudonymization. Copies and extracts inherit the limits of the source, so a purpose is not lost when data moves into a warehouse, a test environment or a spreadsheet, and an internal request for personal data is answered against the purpose it was collected for rather than against the seniority of whoever asked. | Art.6(4) | 4.5, 4.2.4 |
| Resilience & Continuity | ||
| Backups Regular, tested backups of critical data and systems with defined retention, each one a RETRIEVABLE EXACT COPY of the data it protects - complete and restorable, not a partial or lossy snapshot - including a copy taken before equipment holding that data is moved. Backup information is tested on a defined cadence to verify that the media are still reliable and the information still has its integrity - a restore actually performed, not a job that reported success - and it is protected by cryptographic mechanisms so a copy obtained by somebody who should not have it discloses nothing and cannot be altered undetected. Copies are held somewhere other than where the original lives: an alternate storage site is established, with the agreements needed to store backups there and to retrieve them when they are wanted, carrying security controls equivalent to those at the primary site rather than weaker ones because it is only a copy. The alternate site is chosen far enough from the primary that the same fire, flood, outage or regional event is unlikely to take both, and the organization identifies in advance the problems that would make the site hard to reach during a wide-area disruption - roads, transport, staff availability, network dependency - and states explicit mitigation actions for each rather than discovering them on the day. The recovery itself is a documented process and not only a schedule: it states which assets are in scope for recovery, the order in which they are brought back, and how the backup data is protected while it waits, and it is reviewed and updated on a defined cadence and whenever a change to the organization would alter it. Recovery data carries protection EQUIVALENT to the data it copies rather than weaker protection because it is a copy. And at least one instance of it is ISOLATED - held offline, off-site, or in a separately controlled service, out of reach of the credentials and the network paths that operate the live environment - so an event that reaches production does not also reach the copy that would undo it. Verification is performed at the point of USE as well as on the cadence: before a backup or any other restoration asset is relied on to bring a system back, its integrity is checked against the value recorded when it was taken and the check is logged - so a restoration does not carry corrupted or tampered data into a system that has just been cleaned. | Art.32(1) | 4.7.1 |
| Incident response A documented, tested plan to detect, triage, contain, remediate, and communicate security incidents, and to mitigate - so far as is practicable - the harmful effect of a use or disclosure of personal data the organization knows breached its own policies or the law. Each incident is recorded together with its outcome - what happened, what was done about it and how it ended - as a record of that incident, which is a different artifact from the plan being documented. The mitigation duty runs to violations by the organization itself AND to violations by the processors, vendors and other parties handling that data on its behalf: the plan reaches an incident somebody else caused with the organization’s data, so learning of one triggers the same containment and remediation as an incident inside its own walls rather than a request that the other party deal with it. Where an incident carries a duty to tell someone outside the organization, the plan discharges it on the clock the applicable law sets - and, where the organization has itself committed to a timeframe for telling people, on that commitment too, whether or not a statute stands behind it - rather than whenever the investigation happens to conclude: whether an incident is notifiable is decided against written criteria rather than argued after the fact, the regulator or supervisory authority is notified inside the deadline that regime states and inside any shorter or additional timeframe the organization has committed to, the people whose data is affected are told where the risk to them warrants it and, independently of that threshold, wherever the organization’s own privacy commitments say they will be told - so individual notification is never conditioned solely on a statutory risk test - and any other party that law or those commitments require to be notified is told on the same terms, and where a deadline is missed the notification itself explains the delay instead of passing over it. What a notification carries is fixed in advance rather than composed under pressure: to a regulator it describes at least the nature of what happened, including where possible the categories and the approximate number of people affected and of records involved; names a contact point - the data protection officer where there is one, otherwise whoever can answer - from whom more can be obtained; describes the likely consequences; and describes the measures taken or proposed to address it, including where appropriate the measures that will mitigate its adverse effects. Where all of that cannot honestly be given at once, it is given in phases without further undue delay rather than held back until the picture is complete, and each phase says what is still outstanding. The communication to the people affected describes what happened in clear and plain language and carries the same contact point, likely consequences and measures. Every compromise of personal data is documented whether or not it turned out to be notifiable - the facts of it, its effects, and the remedial action taken - in enough detail that a regulator reviewing the file can verify for itself that the notification decision was the right one. Recovery is part of the plan rather than something that follows it: service and data are restored to a state the organization has established is clean, the restoration is verified before the system is handed back to use, the cause is determined rather than inferred from the symptom, and the weakness the incident exposed is fixed - with the plan itself updated for what the incident showed about it. Between the report and the response sits an assessment step that is a duty of its own: every reported event is assessed against written categorization and prioritization criteria by people competent to apply them, and the decision - whether this event is an incident, and at what severity - is recorded with the reasoning, so two assessors reach the same answer and an event judged not to be an incident is a decision somebody made rather than a report that went quiet. Learning is treated as a duty separate from fixing the incident in front of you: the types, volumes and costs of incidents are quantified and reviewed as a set for what the pattern says, and what is learned is pushed back into the controls, the risk assessment, the awareness material and the assessment criteria themselves rather than staying in the report of the incident that produced it. The plan is a documented incident response policy with supporting procedures, issued to the roles it binds, owned by a named role, and reviewed and updated on a defined cadence. The people the plan assigns roles to are trained for them: within a defined period of taking the role, again when the system or the plan changes in a way that affects it, and on a defined cadence thereafter, with the content revised for what exercises and real incidents have shown. The capability is TESTED rather than assumed - on a defined cadence, using tests the organization has chosen for the purpose, such as a tabletop, a walkthrough, a simulation or a live exercise - and that testing is coordinated with the organizational elements that own the related plans, incident response and contingency planning in particular, so the two do not each assume the other. Handling and reporting are supported by automated mechanisms rather than run by hand at the worst moment: detection, triage, tracking, evidence collection and the routing of a report are automated so far as the organization’s systems allow, and the reports that must go outside are produced and sent by mechanism rather than composed under pressure. The roles the plan assigns are named across the functions an incident actually needs and not security alone - legal, IT, information security, facilities, communications, human resources, the responders and the analysts - and the assignment is reviewed on a defined cadence. So are the CHANNELS: a primary and a secondary mechanism for communicating and reporting during an incident are chosen in advance, on the understanding that the ordinary one may be the thing that is unavailable or compromised, and both are reviewed on the same cadence. The plan reaches the parties outside the organization that an incident actually involves: the suppliers and other third parties whose services, staff or systems would be part of the response are named in it, take part in the planning and the exercises, and are called on during response and recovery on terms agreed in advance rather than negotiated during the event. ESCALATION is a defined step and not a judgment call - the plan states the conditions under which an incident is escalated or elevated, whether by severity, by elapsed time, by the functions it has reached or by the obligations it triggers, who it goes to at each step, and what changes when it gets there. The analysis establishes what actually took place during the incident as well as why it happened, and the incident’s magnitude - how many systems, records and people it reached, and over what period - is estimated as the investigation proceeds and then VALIDATED against the evidence rather than left at the first number anybody said out loud. Notification runs to internal stakeholders as well as external ones, so the functions inside the organization that have to act on an incident are told on the same defined terms as the parties outside it. And containment is followed by ERADICATION as a separate act: the malicious code, the unauthorized access and the persistence left behind are removed and their removal is confirmed, so a contained incident is not mistaken for a finished one. | Art.33(1), Art.33(3), Art.33(4), Art.33(5), Art.34(1), Art.34(2) | 10.1(1), 10.1(2), 10.1(3), 10.1(4), 10.1(5), 10.1(6), 10.2(1), 10.2(2), 10.3(1), 10.3(2) |
| Third-party Risk | ||
| Third-party / vendor risk management Due diligence, contractual safeguards, and ongoing monitoring of vendors that handle your data: the agreement obliges the vendor to comply in its own right with the security requirements that apply to it - an absolute standard, not a promise to match whatever you happen to do - to pass those obligations down to any subcontractor it brings in BY ENTERING INTO a contract or equivalent written arrangement with that subcontractor rather than by merely requiring equivalent practice of it, and to report to you, within a stated time, security incidents it becomes aware of and confirmed breaches of your data. Where a contract is not the instrument available, an equivalent written arrangement carrying the same obligations discharges the duty. The same obligations, together with the separation that keeps a related organization out of data it is not entitled to, are written into the governing document of any other arrangement that puts your data in the hands of a sponsor, parent, affiliate or plan. Diligence is not confined to security where the relationship warrants more: for suppliers significant enough to matter, the organization states the standards of conduct it expects of them - how they behave commercially and how they treat the environment around their operations - and screens candidates and incumbents against those stated expectations as part of the same selection and monitoring cycle, rather than accepting a signature on a code as evidence of it. Where the vendor handles personal data, the agreement binds it to privacy obligations no weaker than the commitments the organization has itself made about that data - the purposes it may be used for, the limits on passing it on further, and the help the organization needs in order to answer the requests individuals make about it - and the reporting duty above reaches a suspected as well as a confirmed compromise of that personal data, on the same stated clock. Which requirements apply to a given supplier is decided by the TYPE of relationship rather than by one clause set issued to everyone - what data it touches, what access it holds, whether it can affect the organization’s own service, and what it would cost if it failed - and the requirements are agreed and recorded before access begins rather than negotiated after go-live. Once the relationship is running, what the supplier actually delivers is reviewed against what was agreed on a stated cadence: the service records, the security reports and assurance the agreement entitles the organization to, the incidents it has declared, and the findings of any audit or test right the organization holds - exercised rather than merely retained. A change on the supplier’s side is managed as a change rather than discovered - a new subcontractor, a new location or jurisdiction, a change of ownership, a material change to the technology or to the people delivering the service is notified in advance under the agreement, assessed for what it does to the risk, and approved or refused before it takes effect. ACQUISITION is governed as its own act, under a documented system and services acquisition policy with supporting procedures, owned by a named role and reviewed on a defined cadence. When a system, a component or a service is bought, the contract states the security and privacy requirements it must meet - the functional requirements, meaning what the controls have to do; the strength requirements; the assurance requirements, meaning what evidence the supplier must produce that they work; the documentation the supplier must deliver and how it must be protected and distributed; the description of the development environment and of the environment the product will run in; and the acceptance criteria the delivery is measured against - all stated in the solicitation before a supplier is chosen rather than negotiated after award, and all expressed in terms of the applicable laws and standards. The supplier is required to describe the functional properties of the controls it will implement, and to provide design and implementation information for those controls at a level of detail the organization has specified, so the organization can judge them rather than take their existence on trust. It is also required to identify the functions, ports, protocols and other services the delivered product intends to use in the organization’s environment - and, for an external service provider, the ones its service requires - so an integration does not open a path nobody asked for. The program has three artifacts of its own. An INVENTORY of service providers lists every one the organization knows of, records the classification given to it and names the person inside the organization who owns the relationship, and is reviewed on a defined cadence and whenever a change to the organization would alter it. A POLICY governs the whole cycle - how providers are classified, how the inventory is kept, how they are assessed, how they are monitored and how they are decommissioned - owned by a named role and reviewed on the same terms. And a CLASSIFICATION is applied to each provider against stated criteria such as the sensitivity and volume of the data it holds, the availability the organization depends on it for, the regulation that reaches it, and the risk that remains after the controls in place - reviewed rather than assigned once. DECOMMISSIONING is performed rather than allowed to lapse: when a relationship ends, the user and service accounts are deactivated, the data flows into and out of the provider are terminated, and the organization’s data held in the provider’s systems is disposed of and the disposal evidenced. Who does what is settled before the relationship starts and written down on both sides: the cybersecurity roles and responsibilities of the organization, of the supplier, and of the customers and partners the arrangement reaches are established, communicated to each of them and coordinated between them, so a duty is not left in the gap where each party assumed the other held it. Planning and due diligence come before the agreement rather than after it - what the relationship would expose, what the candidate’s security actually looks like, and what would have to be true before it starts are established while declining is still an option. The risk a supplier carries is then held as a record rather than as an impression: understood, written down, prioritized against the other suppliers, assessed on a stated cadence, responded to with an owner and a date, and monitored for the whole life of the relationship instead of at onboarding only. The provider inventory records the SERVICES each one actually provides as well as its name, so what the organization has placed outside itself is answerable from the list. Where a PROCESS itself is provided from outside, it stays inside the management system’s control rather than leaving it: the controls the organization intends to apply to the external provider and the controls it intends to apply to the resulting output are defined separately and both are applied, because a well-governed supplier can still ship a nonconforming output. What the arrangement could do to the organization’s own ability to consistently meet its customers’ requirements is considered when those controls are set, and the verification or other activity necessary to establish that what arrives meets requirements is determined in advance and carried out rather than inferred from the supplier’s own assurances. | Art.28(1), Art.28(3) | 4.1.3 |
| People & Culture | ||
| Security awareness training Ongoing security and data-handling awareness training for all personnel, with completion tracking, and periodic security updates - reminders, bulletins and alerts - issued to the workforce between training cycles. New joiners are trained within a defined period of starting, anyone whose work is affected is retrained within a defined period after a material change to the policies or procedures, and every completion is recorded. The program itself rests on a documented awareness and training policy with supporting procedures, issued to the people and roles it binds, owned by a named role, and reviewed and updated on a defined cadence rather than at whatever point somebody notices it is stale. The curriculum names two threats explicitly, because both are answered by a person rather than by a system. The first is INSIDER THREAT: what the potential indicators look like - unexplained access outside a role, bulk copying, hostility after a disciplinary or a passed-over promotion, working around a control rather than raising it - and where to report a concern about a colleague, without the reporter being asked to conclude anything. The second is SOCIAL ENGINEERING AND SOCIAL MINING: the phishing message, the pretext phone call, the urgent request from an apparent executive, the person following somebody through a door, and the slower pattern of harmless-seeming questions that assembles into an answer nobody would have given at once - together with the instruction to report both the attempts that worked and those that did not. The curriculum is stated as a set of topics rather than left to whoever assembles the material. AUTHENTICATION: how multi-factor authentication works and why it is required, what makes a passphrase strong, and how credentials are stored and never shared. DATA HANDLING: how to identify sensitive information and how to store, transfer, archive and destroy it, together with the clear screen and clear desk habits that go with it - locking a screen on standing up, clearing a whiteboard at the end of a meeting, and putting paper and portable media away rather than leaving them out. UNINTENTIONAL EXPOSURE: the ways data leaves by accident, such as a message sent to the wrong recipient, a portable device left behind, or a file published to a wider audience than intended. INCIDENTS: how to recognize that something may be an incident and how to report it without first establishing that it is. MISSING UPDATES: how to tell that an asset is not receiving its security updates, and to report a failure of an automated patching tool rather than assume somebody is watching it. INSECURE NETWORKS: the risk of connecting to and sending organizational data over networks the organization does not control, including what is expected of a home network where people work from one. And beyond the common curriculum, ROLE-SPECIFIC training is given where a role carries specific risk - system administration, secure development, and the roles most likely to be targeted directly. | Art.32(4) | 4.1.4, 4.7.4 |
| Physical & Environmental | ||
| Physical security Physical access to facilities and equipment holding sensitive data is restricted and monitored, and a person’s access is validated against the role or function that justifies it rather than only logged; visitors are controlled as a case of their own, and so is access to software programs held for testing and revision. The facility and the equipment in it are safeguarded against tampering and theft as well as against unauthorized entry, and so is the SUPPORT INFRASTRUCTURE the systems depend on - the power feed and its distribution, the cabling and patching, the cooling and environmental plant, the fire detection and suppression, and the points at which communications enter the building - which is protected and monitored on the same terms rather than treated as building services somebody else owns, because a system is stopped as surely by reaching its power or its cooling as by reaching its data. The people who have to reach the site and the equipment when a continuity or recovery plan is invoked can still get in, by a route that is planned rather than improvised; and repairs and modifications to the physical security components of a facility - doors, locks, walls, and the hardware that controls entry - are recorded. The offices, rooms and facilities themselves are designed and fitted for that job rather than simply occupied: rooms holding sensitive information or the equipment that processes it are sited away from public access and from routes people pass through for other reasons, the building’s signage, directories and public information do not advertise where sensitive processing happens, doors, windows, walls and any shared boundary with another tenant are specified against the risk the room actually carries, and a room is locked and checked when it is unoccupied rather than left secured by whoever was last out. Monitoring is continuous rather than periodic: the premises are watched for unauthorized physical access by detection suited to the site - intruder alarms, cameras, contact and motion detection, staffed reception or patrols - covering every way in including delivery and fire doors and including the hours nobody is there, with an alarm going to somebody who responds and a stated response. The monitoring system is protected in its own right, so its configuration, its coverage and its recordings cannot be altered or read by the people it is watching, and recordings are retained and handled under the privacy rules that apply to them. The detection is specified rather than generic: intrusion alarms and surveillance equipment are employed as the means of monitoring physical access, and what they cover, what raises an alarm and who responds is decided in advance. Visitors are escorted for the whole time they are inside a controlled area and their activity while there is monitored, rather than being signed in at a desk and then left to move around; that applies to contractors, delivery and service personnel and auditors alike, and where somebody is authorized to work unaccompanied that is a recorded decision rather than a courtesy. Visitors leave a record: who came, who they were visiting, when they arrived and left, and the identification presented; the record is retained for a defined period, reviewed on a defined cadence rather than only after an incident, and anomalies in it are reported to a designated role. Deliveries and removals are controlled as a class - system components and equipment entering or leaving the facility are authorized before they move, the movement is monitored, and a record of what came in and what went out is kept - and the delivery area itself is arranged so that a delivery does not become unescorted access to the interior. PHYSICAL ACCESS IS LOGGED and not only permitted: entry to the facility and to each controlled area inside it is recorded - who entered, which area, and when - by the entry system, the staffed reception, the visitor register or a combination of them, and the log is retained for a defined period and reviewed on a defined cadence, so a person can be placed in a room at a time and matched against what the systems in it recorded. PHYSICAL ACCESS DEVICES are managed as a controlled inventory rather than handed out: the keys, locks, combinations, badges, cards, fobs and biometric enrollments that open a door are listed with the holder of each, issue and return are recorded against that person, the inventory is reconciled on a defined cadence, and combinations are changed and locks re-keyed when a device is lost or stolen, when a holder leaves or moves, and on the cadence the organization has set rather than only after an incident. All of this rests on a documented physical and environmental protection policy with supporting procedures, issued to the roles it binds, owned by a named role and reviewed on a defined cadence. | Art.32(1) | 4.7.3 |
Beyond the pair
Where else this work counts
A framework is lit when a shared control above also maps to it. Unlit means none of them do — an absence, not a judgment about that standard.
Also reached by these 22 controls
- AI Governance Essentials also reached
- Amazon Appstore Child-Directed Apps not reached
- Apple App Store Kids Category not reached
- CIS Critical Security Controls also reached
- COPPA also reached
- ESG Essentials also reached
- EU AI Act not reached
- Google Play Families not reached
- HIPAA also reached
- ISO 9001 also reached
- ISO/IEC 27001 also reached
- ISO/IEC 42001 not reached
- NIST AI Risk Management Framework not reached
- NIST Cybersecurity Framework also reached
- NIST SP 800-171 also reached
- NIST SP 800-53 also reached
- PCI DSS also reached
- SOC 2 also reached
- SOX (Sarbanes-Oxley) Section 404 also reached
- US Employment Law - Federal Baseline also reached
The thesis
Why this is one project, not two
On a crosswalk-native model, PIPEDA mostly lights up controls you already built for GDPR. You’re not re-uploading the same screenshot for a second audit. You apply the framework and see the genuine delta worth working. That’s the whole idea behind collect once, comply everywhere.
Next step
Add PIPEDA to the work you already did
Apply both frameworks in one workspace and see the overlap measured against the controls you already hold.