ISO 27701:2019

Structural note stating that the guidance of clause 6 together with the additions in this clause form the PIMS-specific guidance for an organization acting as a PII controller, and that the guidance here relates to the controls listed in Annex A. It carries no obligation of its own.

• Nothing is auditable against this entry.
• Applicability of this clause follows from the role determination evidenced under 5.2.1

• Counted as a control, inflating the controller control set
• Read as an obligation when the obligations are in 7.2 onward

Control objective for the collection and processing conditions: the organization must determine and document that its processing is lawful, resting on a legal basis valid in the applicable jurisdictions, and carried out for purposes that are clearly defined and legitimate.

• Documented purposes and legal bases across all processing activities
• Records demonstrating the objective is met, not merely stated
• Evidence the position is revisited when purposes change

• Objective satisfied for flagship systems while smaller processing activities have no recorded basis
• Purposes defined so broadly that they cannot be tested for legitimacy
• Legal basis assigned once and never revisited when the purpose extended

The organization must identify and document the specific purposes for which personal data will be processed, documented clearly and in enough detail to be usable in the information given to individuals, in obtaining consent, and in the records of policies and procedures, so that individuals understand why their data is processed.

• Purpose register at the level of the processing activity, not the system
• Evidence the documented purpose text is the text actually used in notices and consent
• Review record showing purposes are updated when processing changes

• Purposes written as business objectives such as improving service, too vague to test any later processing against
• Purpose documented internally in different words from the notice given to individuals, so the two can drift
• One purpose recorded for a system that in fact serves several
• Purpose register produced for a certification and never maintained

The organization must determine, document and comply with the lawful basis for each processing activity against its identified purposes, documenting the basis per activity, including any special categories of personal data in its classification scheme with awareness that the classification and its consequences vary by jurisdiction and regime, and revisiting the basis and any need for fresh consent whenever purposes change or extend.

• Lawful basis recorded against each processing activity, with the reasoning
• Where legitimate interests is relied on, the balancing against obligations to individuals
• Classification scheme entries covering special categories, mapped to the jurisdictions that define them
• Change control showing the basis was re-evaluated when a purpose changed

• Consent recorded as the basis for processing that is in fact contractual, creating a withdrawal right the organization cannot honour
• Legitimate interests asserted with no balancing recorded
• Special categories identified under one jurisdiction's definition while operating under several
• Purpose extended by a new feature with the legal basis never re-examined
• Basis held at organization level rather than per activity

The organization must determine and document a process by which it can demonstrate whether, when and how consent to processing was obtained, clearly documenting when consent is needed and what obtaining it requires, correlating purposes with how consent is obtained, and taking into account jurisdiction specific requirements such as consent not being bundled with other agreements and additional requirements for particular collections or for particular individuals such as children.

• Documented consent process covering when consent is required and what valid consent demands
• Mapping from each purpose to whether and how consent is obtained
• Analysis of jurisdiction specific consent requirements and how the mechanism meets them
• Provision for heightened requirements such as children or research collections

• Consent bundled into terms of service acceptance, which several jurisdictions treat as no consent at all
• One consent mechanism for all purposes, so a person cannot agree to one and refuse another
• Age assurance absent where children's data is foreseeably collected
• The process described but never mapped to purposes, so nobody can say which purposes rest on consent

The organization must obtain and record consent according to its documented process, recording it so that on request it can produce the details of the consent given, including when it was given, the identity of the individual and the consent statement itself, having first provided the information required before consent, and the consent must be freely given, specific as to the purpose, and unambiguous and explicit.

• Consent records holding timestamp, individual identity and the exact statement consented to
• The version of the information presented before consent, retained alongside
• Evidence consent was freely given, meaning a real alternative existed
• Ability to produce a single individual's consent history on request

• Consent recorded as a boolean flag with no record of what wording the person actually saw
• Consent statement changed without versioning, so old consents cannot be interpreted
• Consent obtained as a condition of a service that does not need it, which is not freely given
• Consent stored in a marketing platform outside the retention and access regime
• Pre-ticked or inferred consent recorded as explicit

The organization must assess whether a privacy impact assessment is needed and carry one out where appropriate whenever new processing of personal data or a change to existing processing is planned, determining the elements the assessment needs, which can include the types of personal data processed, where it is stored and where it may be transferred, supported by data flow diagrams and data maps, and recognising that some jurisdictions mandate an assessment for cases such as automated decisions with legal effect, large scale processing of special categories, or systematic large scale monitoring of public areas.

• Documented trigger criteria for when an assessment is required, including the mandated cases
• Screening records showing the need was assessed even where no assessment followed
• Completed assessments with data types, storage locations, transfers and data flows
• Evidence assessment findings changed the design or were formally accepted
• Link from the change process into the screening step

• Assessment performed only for projects that reach a funding threshold, so small high risk changes escape
• Screening decisions not recorded, so the absence of an assessment cannot be justified
• Assessment completed after go live, when it can no longer influence anything
• Findings recorded with no owner, so mitigations are never implemented
• Data flows described in prose without identifying transfers out of jurisdiction

The organization must have a written contract with every processor it uses and must ensure those contracts address implementation of the appropriate processor controls, requiring the processor to implement them in light of the risk assessment and the scope of processing it performs, with all such controls assumed relevant by default and any decision not to require one justified in the Statement of Applicability, responsibilities being allocable differently between the parties provided every control is considered and documented.

• Written contract with every processor, with a register reconciling contracts to processors actually used
• Contract terms addressing the processor control set
• Justification for any processor control not required, recorded in the Statement of Applicability
• Evidence the risk assessment and processing scope informed which controls were required

• Processors engaged under standard purchasing terms with no privacy schedule
• Contract requiring appropriate measures generically, so no specific control is enforceable
• Controls omitted by silence rather than by justified exclusion
• Processor register incomplete, most often missing tools adopted by individual teams
• Contract signed at onboarding and never revisited when the scope of processing grew

Where the organization is a joint controller, it must determine the respective roles and responsibilities for processing, including privacy and security requirements, transparently and in a contract or similar binding document covering matters such as the purpose of the sharing, the parties, the categories of data shared, the processing operations, the allocation of technical and organizational measures, responsibility in the event of a breach including who notifies and when, retention and disposal terms, liabilities, how obligations to individuals are met and how they can obtain information, and a contact point for individuals.

• Binding joint controller agreement covering each of the matters the standard lists
• Identification of every joint controller relationship, distinguished from processor relationships
• Named contact point for individuals and evidence it is reachable
• Breach responsibility allocation naming who notifies whom and within what time
• Information made available to individuals about the essence of the arrangement

• Joint controllership misclassified as a processor relationship, so the wrong contract terms apply
• Agreement covering commercial matters while breach notification and obligations to individuals are unaddressed
• No contact point, leaving individuals to guess which party to approach
• Arrangement never disclosed to individuals in any form
• Retention terms unstated, so each party retains on its own schedule

The organization must determine and securely maintain the records that support its obligations for processing, typically an inventory of processing activities covering the type of processing, its purposes, the categories of personal data and of individuals including any special cases such as children, the categories of recipients including those in third countries or international organizations, a general description of the technical and organizational security measures, and the privacy impact assessment report, with a named owner responsible for the inventory's accuracy and completeness.

• Processing inventory carrying each required element
• Named owner accountable for its accuracy and completeness
• Evidence the inventory is maintained through change, not rebuilt for audits
• Secure storage and access control over the inventory itself
• Linkage from inventory entries to the corresponding impact assessments

• Inventory owned by nobody, so it decays between audits
• Recipient categories recorded without third country recipients, hiding the transfers
• Inventory built from a system list, so processing done in spreadsheets and by suppliers is missing
• Security measures described identically for every activity, which tells a reader nothing
• Inventory itself unprotected despite mapping exactly where the organization's personal data lives

Control objective for obligations to individuals: the organization must ensure individuals are given appropriate information about the processing of their personal data and that any other applicable obligations owed to them in connection with that processing are met.

• Evidence of information provision and of the mechanisms that deliver each obligation
• Performance data on how obligations are met in practice
• Coverage across all processing activities, not the flagship ones only

• Objective met through a published notice with no mechanism behind the rights it describes
• Obligations met manually at volumes that will not scale
• No measurement, so failure is invisible until a complaint

The organization must determine and document its legal, regulatory and business obligations to the individuals whose data it processes and provide the means to meet them, ensuring those means are accessible and timely, giving clear documentation to the individual of the extent to which obligations are fulfilled and how, along with an up to date contact point provided through a channel similar to the one used to collect the data and the consent.

• Register of obligations owed to individuals, by jurisdiction and processing activity
• Documented mechanism delivering each obligation, with the responsible owner
• Published description for individuals of what is fulfilled and how
• Contact point on the same channel used for collection, with monitoring evidence

• Obligations listed by jurisdiction with no mechanism mapped against them
• Contact point offered by post or telephone when the data was collected online, which is a barrier not a channel
• Means provided but not resourced, so timeliness fails under any real volume
• Business obligations, meaning contractual promises made to customers, omitted from the register

The organization must identify and address the obligations, including legal obligations, that it owes to individuals arising from decisions it makes about them based solely on automated processing of their personal data, taking account of jurisdictions that impose specific obligations where such decisions significantly affect the individual, such as notifying that automated decision making exists, allowing objection to it, or providing human intervention, and of jurisdictions where some processing may not be fully automated at all.

• Inventory of decisions made solely by automated processing, with their effect on individuals assessed
• Obligations register per jurisdiction for those decisions
• Notification content disclosing the existence and logic of automated decision making
• Documented human intervention route with evidence it is genuine and available
• Objection route specific to automated decisions

• Automated decisions unrecognised as such because a person nominally approves an output they never question, which is not meaningful human involvement
• Inventory covering the obvious scoring engine while automated rules embedded in workflow tools go unlisted
• Human intervention offered on a channel that has no authority to overturn the decision
• Jurisdictions that prohibit fully automated decisions in the relevant context not identified
• Notification stating that automation is used without conveying the significance to the individual

The organization must determine and document what information is to be provided to individuals about the processing of their data and when it is to be provided, working out the legal, regulatory and business requirements for timing and content, which typically covers the purpose, the controller's contact details, the lawful basis, the source where data was not obtained from the individual, whether provision is statutory or contractual and the consequences of not providing it, the obligations owed and how to benefit from them including access, amendment, correction, erasure, obtaining a copy and objecting, how to withdraw consent, transfers, recipients or categories of recipients, the retention period, any automated decision making, the right to complain and how, and how often information is provided, updated whenever purposes change or extend.

• Documented determination of notice content and timing per processing activity
• Traceability from each required content element to where it appears in the notice
• Trigger and evidence for updating notices when purposes change
• Legal review record supporting the content decisions

• Notice content copied from a template, so elements that do not apply are present and elements that do are missing
• Source of indirectly collected data omitted, which is the element most often absent
• Retention period expressed as as long as necessary, which conveys nothing
• Timing never determined, so information is given at account creation and never again
• Automated decision making not disclosed because the business does not think of its scoring as automated

The organization must give individuals clear and easily accessible information identifying the controller and describing the processing of their data, delivered in a timely, concise, complete, transparent, intelligible and easily accessible form using clear and plain language suited to the audience, given at the time of collection where appropriate and permanently accessible thereafter.

• The notice as actually presented, in each channel and language used
• Evidence of delivery at the point of collection
• Evidence of permanent accessibility after collection
• Readability or comprehension assessment appropriate to the audience, especially where children are involved

• Notice legally complete and written at a reading level the audience cannot use, which fails the intelligibility requirement
• Notice linked at collection and then buried, so it is not permanently accessible in practice
• Notice available in the organization's language only while collection happens in others
• Layered notice whose top layer omits something material rather than summarising it
• Notice provided after collection where before was practicable

The organization must provide a mechanism for individuals to modify or withdraw consent, inform them of their rights to withdraw at any time, use a withdrawal mechanism consistent with the one used to obtain consent, treat modification as capable of restricting processing including restricting deletion in some cases, record withdrawal or change requests as it records consent itself, disseminate any change through its systems to authorized users and relevant third parties, and define and meet a response time, with processing already performed before withdrawal remaining appropriate but its results not used for new processing.

• Withdrawal mechanism on the same channel as consent collection
• Withdrawal records held to the same standard as consent records
• Evidence of propagation to internal systems and to third parties who received the data
• Defined response time and performance against it
• Rules preventing further use of results derived from withdrawn consent

• Withdrawal accepted centrally and never propagated, so downstream systems keep processing
• Withdrawal harder than consent, for example consent by one click and withdrawal by written request
• Derived artefacts such as profiles and models retained and still used after withdrawal
• Third parties who received the data never told
• No response time defined, so withdrawal is honoured whenever someone gets to it

The organization must provide a mechanism for individuals to object to the processing of their data, documenting the legal and regulatory requirements relating to objection such as objection to direct marketing, informing individuals of their ability to object in those situations, and providing a mechanism consistent with the type of service, so that an online service offers the capability online.

• Objection mechanism appropriate to each service channel
• Register of the objection rights that apply, by jurisdiction and processing type
• Information given to individuals about when they may object
• Objection records and evidence processing actually stopped

• Objection conflated with consent withdrawal, so objections against non consent based processing have no route
• Marketing suppression applied in one system while other systems continue to select the individual
• Objection right described in the notice with no mechanism behind it
• Objections recorded as complaints and closed rather than actioned as a standing instruction

The organization must implement policies, procedures or mechanisms enabling individuals to obtain access to, correct and erase their personal data without undue delay, must define and meet a response time, must disseminate corrections and erasures through its systems and to authorized users and pass them to third parties who received the data, must have a route for disputes about accuracy or correction that includes telling the individual what changes were made and why corrections could not be made where that is so, and must keep current with jurisdictional restrictions on when and how these requests may be made.

• Documented procedures for access, correction and erasure with defined response times
• Request log with dates received and completed, and performance against the response time
• Evidence corrections and erasures propagated to all systems and to third parties
• Dispute procedure including notification of changes made and reasons for refusal
• Register of jurisdictional restrictions on these rights

• Erasure performed in the primary system while backups, archives, logs and analytics copies retain the data
• Access requests answered from one system because no map exists of where else the person's data sits
• Corrections applied without propagation, so systems disagree about the same person
• Refusals given without reasons, which the standard requires be explained
• Response times defined in policy and not measured in practice

The organization must inform third parties with whom personal data has been shared of any modification, withdrawal or objection affecting that data and must implement policies, procedures or mechanisms to do so, taking appropriate steps bearing in mind available technology, determining and maintaining active communication channels with those third parties, assigning responsibility for operating and maintaining them, and monitoring the third parties' acknowledgement of receipt.

• Register of third parties who have received personal data, per processing activity
• Documented notification mechanism per third party with a named owner
• Notification records with acknowledgements of receipt
• Evidence channels are tested and kept live rather than assumed

• Third parties recorded at the point of sharing and never maintained, so the register is stale when it is needed
• Notifications sent with no acknowledgement tracked, so nobody knows whether they landed
• Channel is a named individual's email address, which fails when that person leaves
• Only consent withdrawals propagated, with corrections and objections left behind
• Historic recipients from before the register existed never brought into scope

The organization must be able to provide a copy of the personal data it processes when the individual asks, in a structured and commonly used format accessible to that individual, portable and machine readable where the jurisdiction requires it, ensuring the copy relates only to that individual, informing them where the requested data has already been deleted under the retention policy, not seeking to re-identify individuals solely to satisfy this control where it can no longer identify them, and enabling direct transfer to another organization at the individual's request where technically feasible.

• Documented export capability with the formats supported
• Evidence exports are scoped to the requesting individual only
• Procedure for informing an individual that data has already been deleted
• Position on re-identification, recording that it is not attempted merely to answer a request
• Direct transfer capability where technically feasible, or the assessment that it is not

• Export produced as a screen capture or report rather than a structured format
• Export including other individuals' data present in shared records or free text
• Re-identification attempted on de-identified holdings in order to answer a request, creating the exposure the de-identification removed
• No response where data has been deleted, leaving the individual to assume it is withheld
• Portability treated as identical to access, ignoring the format requirement

The organization must define and document policies and procedures for handling and responding to legitimate requests from individuals, which can include requests for a copy of data or to lodge a complaint, handling them within appropriate defined response times, taking account of jurisdictions that set response times by complexity and volume and that require the individual be told of delay, with the appropriate response times stated in the privacy policy, and of jurisdictions that permit a fee in limited cases such as excessive or repetitive requests.

• Documented request handling procedure covering identification, triage, response and escalation
• Response times published in the privacy policy and measured in operation
• Delay notification procedure and evidence of use
• Complaint route distinct from general customer service, with records
• Fee policy where a fee is charged, with the justification for each charge

• Requests handled through general customer service with no privacy specific triage, so clocks start late
• Response times published but not measured, so breaches are invisible
• No delay notification, so a complex request simply goes quiet
• Complaints resolved individually with no analysis of the systemic cause
• Identity verification demanding more personal data than the request itself involves

Control objective for privacy by design and by default: processes and systems must be designed so that collection and processing, including use, disclosure, retention, transmission and disposal, are limited to what the identified purpose actually needs.

• Design evidence showing limitation applied across the whole lifecycle, not collection alone
• Default settings evidencing minimisation
• Periodic verification that operating systems still match the designed limits

• Minimisation applied at collection while retention, disclosure and transmission are unconstrained
• Defaults set to the most permissive option with minimisation available only on request
• Design intent never verified against what the system does in production

The organization must limit collection of personal data to the minimum that is adequate, relevant, proportional and necessary for the identified purposes, including data collected indirectly through means such as web and system logs, and where any optionality in collection and processing exists each option must be disabled by default and enabled only by the individual's explicit choice.

• Field level justification linking each item collected to an identified purpose
• Assessment of indirectly collected data such as logs, telemetry and tracking
• Evidence optional collection is off by default, captured from the live configuration
• Periodic review of collection against current purposes

• Justification performed for form fields while telemetry, cookies and logs collect far more without review
• Optional processing enabled by default with an opt out, which reverses the required default
• Fields collected because they might be useful later, which is not a purpose
• Legacy fields retained in collection long after the purpose that justified them ended
• Default configuration correct at launch and drifted since, with no verification

The organization must limit processing of personal data to what is adequate, relevant and necessary for the identified purposes, managing that limitation through its information security and privacy policies with documented procedures for their adoption and compliance, and limiting by default the disclosure of data, the period it is stored, and who is able to access it, to the minimum the identified purposes require.

• Policy and procedures constraining processing to the identified purposes
• Access entitlements demonstrably scoped to purpose rather than to job title
• Disclosure rules limiting who outside the organization receives what
• Storage periods set per purpose
• Compliance monitoring against the limitation, not merely its adoption

• Broad internal access granted for convenience, so any employee can read any record
• Limitation stated in policy with no procedure that turns it into a configuration
• Secondary use for analytics or model training treated as within the original purpose without assessment
• Storage period set at the system level rather than per purpose, so the longest purpose governs everything
• Adoption evidenced while compliance is never monitored

The organization must ensure and document that personal data is as accurate, complete and up to date as the purposes for which it is processed require, throughout the data lifecycle, implementing policies, procedures or mechanisms that minimise inaccuracy and that respond to instances of inaccurate data, and including those in its documented information, for example through technical system configurations.

• Documented accuracy standard, expressed relative to the purpose rather than absolutely
• Validation and quality mechanisms at capture and through the lifecycle
• Procedure for responding to discovered inaccuracy, including downstream correction
• Quality measurement results

• Accuracy treated as a data quality initiative for reporting rather than an obligation owed to the individual
• Validation applied at capture with no mechanism to detect data going stale
• Inaccuracy corrected where a person complains and nowhere else
• Accuracy requirement identical across purposes, when a marketing list and a credit decision demand different standards
• Corrections not propagated to systems fed from the corrected source

The organization must define and document data minimisation objectives and the mechanisms used to meet them, identifying how the specific data and the amount collected and processed is limited relative to the identified purposes, describing the processing where the purpose genuinely requires data that has not been de-identified, and where it does not, documenting the extent to which data needs to remain associated with the individual and the mechanisms and techniques, such as generalisation or randomisation, designed to achieve the de-identification or minimisation objectives in a timely manner.

• Documented minimisation objectives, expressed measurably
• Description of the mechanisms and techniques used, including technical configurations
• Justification where processing requires data that is not de-identified
• Assessment of the residual re-identification risk of the techniques chosen
• Evidence the mechanisms operate on a timely basis rather than on request

• Minimisation objectives stated as principles with no measure, so achievement cannot be shown
• De-identification claimed on the basis of removing direct identifiers alone, leaving a readily re-identifiable dataset
• Technique chosen without assessing whether it withstands linkage against other holdings
• Objectives defined and the mechanisms never implemented, so nothing changes in practice
• Timeliness unaddressed, so identifiable data persists long after de-identification became possible

The organization must delete personal data, or render it into a form that does not permit identification or re-identification of the individual, as soon as the original data is no longer necessary for the identified purposes, having mechanisms to erase data when no further processing is anticipated, with de-identification techniques an acceptable alternative only so long as the resulting data cannot reasonably permit re-identification.

• Documented end of processing triggers per purpose
• Deletion or de-identification mechanisms with evidence of operation
• Assessment that de-identified output cannot reasonably be re-identified
• Evidence the mechanisms reach every copy including backups, archives and derived datasets
• Records of deletions or de-identifications performed

• End of processing never determined, so nothing ever triggers deletion
• Deletion in the application only, with the same data intact in warehouses, backups and exports
• De-identification relied on without testing, so the data remains re-identifiable and the obligation unmet
• Manual deletion processes that do not run at the volumes involved
• No record of deletion, so the organization cannot prove it happened

The organization must ensure that temporary files created as a result of processing personal data are erased or destroyed under documented procedures within a specified documented period, performing periodic checks that unused temporary files are deleted within that period, recognising that such files include items like rollback journals and files created by database updates and application operation, that they are not needed once the related task completes but sometimes cannot be deleted immediately, and that their lifetime is not always deterministic so a collection procedure should identify them and determine how long since they were last used.

• Documented procedure naming the temporary file locations and the retention period for each
• Automated or scheduled cleanup with execution evidence
• Periodic verification that unused temporary files were in fact removed
• Inventory of temporary artefacts including rollback journals, caches, spool files and interim exports

• Temporary files unconsidered entirely, so the longest lived copy of personal data is one nobody knows about
• Procedure covering the application's own temporary directory while database, queue and export staging areas go unmanaged
• Cleanup scheduled and silently failing, with no verification to catch it
• Period specified for deletion but not the check that deletion occurred
• Interim files created by analytics and reporting excluded because they are not seen as processing

The organization must not retain personal data longer than the purposes for which it is processed require, developing and maintaining retention schedules that take account of legal, regulatory and business requirements and, where those requirements conflict, taking and documenting a business decision based on a risk assessment and recording it in the appropriate schedule.

• Retention schedule covering every category of personal data, with the period and its justification
• Evidence the schedule is enforced, not merely published
• Documented risk based decisions where legal, regulatory and business requirements conflicted
• Review record keeping the schedule current with legal change

• Schedule published and never enforced, so the actual retention is indefinite
• Single retention period applied across all data because the longest legal requirement was adopted for everything
• Conflicts resolved informally in favour of retention, with no risk assessment or decision record
• Backups, archives and analytics copies outside the schedule
• Schedule written by records management and never reconciled to what systems actually do

The organization must hold documented policies, procedures or mechanisms for the disposal of personal data, choosing disposal techniques with regard to factors including the nature and extent of the data, any associated metadata, and the physical characteristics of the media it is stored on, since techniques differ in their properties and outcomes such as the granularity of the resulting media or whether deleted information can be recovered.

• Disposal policy naming the technique used per media type and data category
• Disposal records identifying what was disposed of, when, by whom and by what method
• Consideration of associated metadata in the disposal decision
• Assurance evidence where disposal is performed by a third party

• One disposal method assumed adequate across all media, ignoring how outcomes differ
• Metadata such as filenames, indexes and audit trails surviving disposal of the data itself
• Third party disposal accepted on a certificate that does not identify the items destroyed
• Cloud held data disposed of by deleting a pointer, with the underlying storage untouched
• Disposal policy written for physical media only while most data is electronic

The organization must subject personal data transmitted over a data transmission network to controls designed to ensure it reaches its intended destination, typically by ensuring only authorized individuals have access to transmission systems and by following processes, including retaining audit logs, that ensure data is transmitted without compromise to the correct recipients.

• Documented transmission controls covering authorisation, protection and recipient verification
• Access controls over transmission systems
• Audit logs of transmissions retained and reviewable
• Evidence of recipient verification, not merely of encryption in transit

• Encryption treated as the whole of the control, with no assurance the data reached the right recipient
• Transmission logs absent, so a misdirection cannot be detected or investigated
• Bulk transfers run by individuals with no authorisation step
• Recipient addresses maintained manually in scripts, where a single edit misroutes a whole file
• Ad hoc transfers by email and file sharing outside the controlled route

Control objective for sharing, transfer and disclosure: the organization must determine and document when personal data is shared, transferred to other jurisdictions or third parties, or disclosed, and do so in accordance with its applicable obligations.

• Documented position on every sharing, transfer and disclosure route
• Records evidencing the objective is met in operation
• Evidence the position is revisited as routes change

• Objective met for planned transfers while ad hoc disclosures go unrecorded
• Transfers documented at contract signature and not as they actually occur
• Jurisdictional analysis performed once and never revisited after a regulatory change

The organization must identify and document the basis on which personal data is transferred between jurisdictions, documenting compliance with the legislation and regulation that applies depending on the jurisdiction or international organization the data goes to and comes from, and being aware that some jurisdictions require transfer agreements to be reviewed by a designated supervisory authority.

• Transfer register naming origin, destination and the documented basis for each transfer
• The transfer instruments themselves, such as contractual clauses or binding rules
• Assessment of destination jurisdiction requirements
• Evidence of supervisory authority review where the jurisdiction requires it

• Transfers identified only where data physically moves, missing remote access from another jurisdiction, which is itself a transfer
• One transfer basis assumed adequate for every destination
• Instruments executed and never revisited after the legal landscape changed
• Supervisory review requirements unidentified, leaving the instrument unenforceable
• Onward transfers by recipients not covered by the basis

The organization must specify and document the countries and international organizations to which personal data can possibly be transferred, making those identities available to customers and including the countries arising from subcontracted processing, considering them in relation to the documented transfer basis, and recognising that transfers made at the request of a law enforcement authority may involve countries that cannot be specified in advance or whose identification is prohibited to preserve the confidentiality of an investigation.

• Documented list of destination countries and international organizations
• Evidence the list is made available to customers
• Inclusion of destinations arising from subcontractors, not the organization's own operations alone
• Reconciliation between the destination list and the transfer bases held
• Process for maintaining the list as subcontractors and regions change

• List covering the organization's own locations while subcontractor destinations are omitted, which is where most undisclosed transfers arise
• List produced at contract signature and never updated as the supply chain changes
• Support and administration access from a country absent from the list, because access is not thought of as transfer
• List published without reconciliation to transfer bases, so a destination appears with no lawful route
• Availability to customers asserted but the list held internally only

The organization must record transfers of personal data to and from third parties and ensure cooperation with those parties to support future requests arising from its obligations to individuals, which includes transfers from third parties of data modified as a result of controllers managing their obligations and transfers to third parties implementing legitimate individual requests such as erasure after consent withdrawal, holding a policy defining the retention period of these records and applying data minimisation so only the strictly needed information is retained.

• Transfer log covering transfers both to and from third parties
• Documented cooperation arrangements supporting later individual requests
• Retention policy for the transfer records themselves
• Evidence of minimisation applied to the content of those records

• Only outbound transfers recorded, so data flowing back after a third party correction is untracked
• Transfer records retained indefinitely, becoming a personal data holding of their own
• Records containing the transferred data rather than a reference to it, which is the opposite of minimisation
• Cooperation assumed rather than agreed, so a later erasure request cannot be propagated
• Logs kept per system, with no way to answer what was transferred about one individual

The organization must record disclosures of personal data to third parties, including what data was disclosed, to whom and at what time, recording disclosures made in the course of normal operations and additional disclosures such as those arising from lawful investigations or external audits, with the records including the source of the disclosure and the source of the authority to make it.

• Disclosure log recording what data, to whom and when, for routine and exceptional disclosures alike
• Source of the disclosure and the authority relied on, recorded per entry
• Coverage of investigation and audit disclosures, not commercial sharing only
• Retention and access controls over the disclosure log

• Routine disclosures logged while law enforcement and audit disclosures are handled outside any record
• Authority for the disclosure not recorded, so the organization cannot later justify it
• Log recording that a disclosure occurred without identifying what data left
• Disclosures made by individual staff outside the logged route
• Log kept by the function that made the disclosure rather than centrally, so no complete picture exists

Structural note stating that the guidance of clause 6 together with the additions in this clause form the PIMS-specific guidance for an organization acting as a PII processor, and that the guidance here relates to the controls listed in Annex B. It carries no obligation of its own.

• Nothing is auditable against this entry.
• Applicability of this clause follows from the role determination evidenced under 5.2.1

• Counted as a control, inflating the processor control set
• Read as an obligation when the obligations begin at 8.2

Control objective for a processor's collection and processing conditions: the organization must determine and document that the processing it carries out is lawful, resting on a legal basis valid in the applicable jurisdictions and serving clearly defined and legitimate purposes, which for a processor means purposes set by its customer's documented instructions.

• Evidence that processing performed maps to documented customer instructions
• Contractual basis for each processing engagement
• Records demonstrating the objective in operation

• Objective evidenced by the contract alone, with no check that actual processing stays inside it
• Instructions received informally and never documented
• Processing added for the processor's own purposes without a separate basis

Where relevant, the contract to process personal data must address the organization's role in assisting the customer with the customer's own obligations, taking account of the nature of processing and the information available to it, covering as relevant privacy by design and by default, achieving security of processing, notifying breaches to a supervisory authority and to customers and individuals, conducting privacy impact assessments, and assuring assistance where prior consultation with a protection authority is needed, with some jurisdictions also requiring the contract to state the subject matter and duration of processing, its nature and purpose, the type of data and the categories of individuals.

• Customer contracts carrying the assistance provisions relevant to the engagement
• Where the jurisdiction requires it, contract terms stating subject matter, duration, nature, purpose, data types and categories of individuals
• Operational capability behind each assistance commitment, not the commitment alone
• Contract register reconciling signed terms to live processing engagements

• Assistance promised in contract with no operational capability behind it, discovered only when the customer first asks
• Breach notification assistance limited to telling the customer, with none of the detail the customer needs to notify a regulator
• Impact assessment assistance omitted, leaving the customer unable to complete one
• Jurisdiction specific content requirements unidentified, so the contract is incomplete where it matters
• Legacy customers on older terms that predate the obligations

The organization must ensure that personal data processed on behalf of a customer is processed only for the purposes expressed in that customer's documented instructions, with the contract stating the objective and time frame of the service, recognising that technical reasons may make it appropriate for the organization to determine the method of processing consistent with general instructions without express direction, and allowing the customer to verify compliance with purpose specification and limitation, which also ensures no data is processed by the organization or its subcontractors for other purposes.

• Documented customer instructions per engagement, with a change route
• Contract terms stating the objective and time frame of the service
• Controls preventing processing outside the instructions, including by subcontractors
• A means for the customer to verify purpose compliance, and evidence it has been offered or used
• Distinction recorded between method decisions taken technically and purpose decisions, which are the customer's

• Customer data used to improve the organization's own products or models, which is a purpose the customer never instructed
• Instructions held as a contract clause with no operational mechanism keeping processing inside it
• Subcontractors processing under the organization's general practice rather than the customer's instructions
• No verification means offered, so the customer must take the position on trust
• Method decisions drifting into purpose decisions with no record of who decided what

The organization must not use personal data processed under a contract for marketing or advertising without establishing that prior consent was obtained from the appropriate individual, and must not make giving that consent a condition of receiving the service; compliance with the customer's contractual requirements must be documented, especially where marketing or advertising is planned, and the organization should not insist on including marketing or advertising uses where express consent has not been fairly obtained.

• Contract terms addressing marketing and advertising use
• Evidence of prior consent where such use occurs, traceable to the individual
• Evidence that consent is not a condition of service
• Documented compliance with the customer's contractual requirements on this point

• Marketing use permitted by a broad clause in standard terms, with no consent behind it
• Consent bundled into service acceptance, making it a condition of receiving the service
• Consent obtained by the customer and assumed by the processor without evidence
• Analytics or profiling for the organization's commercial benefit treated as service improvement rather than marketing

The organization must inform the customer if, in its opinion, a processing instruction infringes applicable legislation or regulation, recognising that its ability to judge that depends on the technological context, on the instruction itself and on the contract between it and the customer.

• Documented route for raising an instruction concern, with the decision authority named
• Records of instructions challenged and the outcome
• Contract terms preserving the ability to raise the concern
• Competence evidence for whoever judges whether an instruction infringes

• No route exists, so a questionable instruction is executed because refusing it has no defined path
• Route exists but sits with account management, whose incentive is to keep the customer
• Concerns raised verbally with no record, so a pattern of them is invisible
• Contract silent, leaving the organization exposed if it declines an instruction

The organization must give the customer the information the customer needs to demonstrate compliance with its own obligations, which can include whether the organization allows for and contributes to audits conducted by the customer or by another auditor the customer mandates or agrees.

• Documented information package provided to customers for their own compliance evidence
• Contract terms on audit rights and how they are exercised
• Records of audits allowed or contributions made
• Evidence the package is kept current

• Assurance offered as a certificate whose scope does not cover the service the customer bought
• Audit rights granted contractually and refused in practice through commercial friction
• Information package written once and stale on control changes
• Customer left to assemble compliance evidence from marketing material

The organization must determine and maintain the records needed to demonstrate compliance with its obligations under the applicable contract for processing carried out on behalf of a customer, recognising that some jurisdictions require recording matters such as the categories of processing carried out for each customer, transfers to third countries or international organizations, and a general description of the technical and organizational security measures.

• Records of processing held per customer, covering the categories of processing carried out
• Record of transfers to third countries and international organizations
• General description of the technical and organizational measures
• Named owner and evidence of maintenance through change

• Records held at organization level rather than per customer, which is what the obligation asks for
• Transfers by subcontractors omitted from the record
• Security measures described identically for every customer regardless of the service tier they bought
• Records rebuilt for audits rather than maintained, so they describe a past state

Control objective for a processor's obligations toward individuals: the organization must ensure that individuals receive appropriate information about the processing of their data and that other applicable obligations owed to them are met, which for a processor is discharged largely by enabling its customer to meet them.

• Evidence of the means provided to customers to meet obligations to individuals
• Contract terms specifying those means
• Operational records of assistance actually given

• Objective treated as belonging wholly to the customer, so no means are provided
• Means provided informally with no contractual specification
• Assistance available in principle at volumes it cannot sustain

The organization must provide the customer with the means to comply with its obligations to individuals, recognising that those obligations may be set by legislation, regulation or contract and may include matters where the customer relies on the organization's services to implement them, such as correcting or deleting data in a timely fashion, and where the customer depends on information or technical measures from the organization to meet its obligations, those must be specified in a contract.

• Documented capabilities for access, correction, deletion, export and restriction, offered to customers
• Contract terms specifying the information and technical measures the customer may rely on
• Service level or response time for assistance, and performance against it
• Evidence the capabilities work at the volumes the customer's obligations imply

• Deletion offered only as a bulk end of contract operation, which cannot serve an individual erasure request
• Assistance provided by manual engineering effort with no service level, so the customer's own deadline is at risk
• Capabilities existing in the product but not specified in the contract, so the customer cannot rely on them
• Correction possible in the primary store while derived and cached copies stay stale
• Assistance excluding data held by the organization's own subcontractors

Control objective for a processor's privacy by design and by default: processes and systems must be designed so that collection and processing of personal data, including use, disclosure, retention, transmission and disposal, are limited to what the identified purpose requires.

• Design evidence covering the whole lifecycle for processing performed on behalf of customers
• Default configurations evidencing minimisation
• Verification that operation matches design

• Design limits set by what the customer asked for rather than by what the purpose needs
• Defaults maximising retention because storage is cheap
• Design intent never verified in production

The organization must ensure that temporary files created as a result of processing personal data are erased or destroyed under documented procedures within a specified documented period, conducting periodic verification that unused temporary files are deleted within that period, recognising that such files include items such as rollback journals and files created by database updates and application operation, are not needed once the related task completes, sometimes cannot be deleted immediately, and have a lifetime that is not always deterministic so a collection procedure should identify them and how long since they were last used.

• Documented procedure naming temporary file locations and their retention period
• Scheduled cleanup with execution evidence and failure alerting
• Periodic verification that unused temporary files were actually removed
• Inventory of temporary artefacts across the multi tenant platform, including per customer staging areas

• Temporary artefacts of one customer's processing persisting on shared infrastructure after the task ends
• Cleanup jobs failing silently with no verification step to catch it
• Procedure covering application temp directories while queues, caches and export staging go unmanaged
• Retention period defined without any check that deletion happened
• Customer data in debug and diagnostic files excluded because they are not seen as processing output

The organization must provide the ability to return, transfer or dispose of personal data securely and must make its policy available to the customer, managing the capability securely whether the outcome is return to the customer, transfer to another organization or controller, deletion, destruction, de-identification or archiving, providing the assurance the customer needs that data processed under the contract is erased by the organization and its subcontractors from wherever it is stored including backup and business continuity copies as soon as it is no longer necessary for the customer's identified purposes, and covering in the policy the retention period before disposal after contract termination so the customer is protected from losing data through an accidental lapse.

• Documented return, transfer and disposal policy, made available to customers
• Assurance evidence that erasure reaches backups, continuity copies and subcontractors
• Stated post termination retention period before disposal, with its rationale
• Records of returns, transfers and disposals performed, per customer
• Contractual flow down obliging subcontractors to erase on the same terms

• Erasure certified for primary systems while backups retain the data for the full backup cycle, which the customer is not told
• Subcontractor copies unaddressed, so erasure assurance is given for data the organization does not control
• No post termination grace period, so an administrative lapse destroys the customer's data
• Grace period indefinite, so terminated customers' data is retained without basis
• Policy held internally and never made available to the customer

The organization must subject personal data transmitted over a data transmission network to controls designed to ensure it reaches its intended destination, typically by ensuring only authorized individuals have access to transmission systems and by following processes, including retaining audit data, that ensure transmission without compromise to the correct recipients, with transmission requirements capable of inclusion in the contract with the customer and, where no contractual requirement exists, advice appropriately taken from the customer before transmitting.

• Documented transmission controls covering authorisation, protection and recipient verification
• Audit data retained for transmissions of customer personal data
• Contract terms on transmission requirements where they exist
• Evidence of consulting the customer before transmission where the contract is silent

• Transmission performed on the organization's own default standard where the customer had a higher requirement it was never asked about
• Encryption applied with no verification that the recipient was the intended one
• Audit data not retained, so a misdirected transmission cannot be traced
• Ad hoc transfers to customer nominated endpoints arranged over email with no authorisation step

Control objective for a processor's sharing, transfer and disclosure: the organization must determine and document when personal data is shared, transferred to other jurisdictions or third parties, or disclosed, and do so in accordance with its applicable obligations, which for a processor means keeping the customer informed and acting only within its authority.

• Documented position on every sharing, transfer, disclosure and subcontracting route
• Evidence the customer is informed as required
• Records demonstrating the objective in operation

• Objective evidenced for contracted transfers while law enforcement disclosures sit outside any record
• Customer informed at contract signature only, not as arrangements change
• Subcontracting treated as a procurement matter rather than a disclosure

The organization must inform the customer in a timely manner of the basis for transfers of personal data between jurisdictions and of any intended changes, so the customer can object or terminate, documenting compliance with the legislation and regulation that applies depending on origin and destination, informing the customer of transfers to suppliers, other parties and other countries or international organizations, giving advance notice of changes within an agreed timeframe, setting the limits of any contractual allowance to make changes without informing the customer, and identifying the instruments relied on for international transfer together with the countries involved and the circumstances in which they apply.

• Documented transfer basis per route, disclosed to the customer
• Notification records for changes, with the agreed advance timeframe
• Contract terms setting the limits of any change made without notification
• Identification of the transfer instruments, the countries and the circumstances in which each applies
• Evidence the customer had a real opportunity to object

• Change notification given after the change took effect, removing the ability to object
• Contractual allowance to change without notice drawn so broadly that the customer effectively waives the control
• Transfer instruments named generically without saying which country each covers
• Remote support access from another jurisdiction not treated as a transfer, so it is never disclosed
• Notification sent to a commercial contact who has no privacy remit

The organization must specify and document the countries and international organizations to which personal data can possibly be transferred, making those identities available to customers and including countries arising from subcontracted processing, considering them against the documented transfer basis, and recognising that transfers at the request of a law enforcement authority may involve countries that cannot be specified in advance or whose identification is prohibited to preserve the confidentiality of an investigation.

• Documented destination list covering the organization and its subcontractors
• Evidence the list is available to customers and kept current
• Reconciliation between destinations and the transfer bases held
• Maintenance process triggered by supply chain and regional change

• Destination list covering hosting regions while support, monitoring and development locations are omitted
• Subcontractor destinations excluded, which is the most common gap and the one customers most need
• List published at onboarding and never refreshed as the platform expands regionally
• Destinations listed with no transfer basis behind some of them
• Follow the sun support arrangements not recognised as creating destinations

The organization must record disclosures of personal data to third parties, including what data was disclosed, to whom and when, recording disclosures made in normal operations and additional disclosures such as those arising from lawful investigations or external audits, with the records including the source of the disclosure and the source of the authority to make it.

• Disclosure log covering routine and exceptional disclosures
• Source of the disclosure and the authority relied on, per entry
• Coverage of investigation and audit disclosures
• Access control and retention rules over the log itself

• Law enforcement and audit disclosures handled outside the logged route
• Log recording that a disclosure occurred without identifying what data left or whose
• Authority not recorded, so the disclosure cannot later be justified to the customer
• Log held by the responding function rather than centrally, so no complete picture exists

The organization must notify the customer of any legally binding request for disclosure of personal data, notifying within agreed timeframes and according to an agreed procedure which can be set out in the customer contract, while recognising that some legally binding requests carry a requirement not to notify anyone about the request, for example a prohibition under criminal law to preserve the confidentiality of an investigation.

• Documented procedure for handling legally binding disclosure requests, including the notification route and timeframe
• Contract terms setting the agreed timeframe and procedure
• Records of requests received, notifications made, and where notification was prohibited, the basis
• Legal review step before any disclosure is made

• Requests handled by whoever receives them, with no procedure and no notification
• Notification prohibition assumed from the tone of the request rather than established legally
• No record kept where notification was prohibited, so the organization cannot show it acted properly once the prohibition lifts
• Timeframe agreed in contract but not achievable by the actual process
• Notification sent to a commercial contact rather than the customer's privacy function

The organization must reject requests for disclosure of personal data that are not legally binding, must consult the corresponding customer before making any disclosure, and must accept contractually agreed disclosure requests that are authorized by that customer, recognising that such requests can originate from courts, tribunals and administrative authorities in any jurisdiction, with implementation detail capable of inclusion in the customer contract.

• Documented rule that non binding requests are rejected, with the assessment step that decides bindingness
• Evidence of customer consultation before disclosure
• Register of requests with the outcome and the reasoning
• Contract terms covering how consultation and authorisation work

• Informal requests from authorities complied with voluntarily, which the control expressly prohibits
• Bindingness judged by operations staff with no legal input
• Customer consulted after disclosure rather than before
• Cross border requests accepted without checking whether the authority has jurisdiction over the organization
• No register, so a pattern of requests about one customer is invisible

The organization must disclose to the customer any use of subcontractors to process personal data before that use, with provisions included in the customer contract, disclosing that subcontracting is used and the names of the relevant subcontractors, the countries and international organizations to which they can transfer data, and the means by which they are obliged to meet or exceed the organization's own obligations, and where public disclosure of subcontractor information would increase security risk beyond acceptable limits, making the disclosure under a non disclosure agreement or on request while making the customer aware the information is available, the list of countries always being disclosed so the customer can inform the individuals concerned.

• Current subcontractor list with names, the countries they can transfer to, and how their obligations are secured
• Evidence of disclosure before use, not after
• Contract provisions covering subcontractor disclosure
• Where disclosure is restricted, the risk assessment behind it and evidence the customer knows the information is available
• Evidence the country list is disclosed in all cases

• Subcontractors disclosed only on request, with customers never told the information exists
• New subcontractors used first and disclosed at the next contract review
• List naming subcontractors without their transfer destinations, so the customer cannot inform individuals
• Security risk cited to withhold the country list, which the standard says must always be disclosed
• Fourth party subcontractors, engaged by the organization's own subcontractors, omitted entirely

The organization must engage a subcontractor to process personal data only according to the customer contract, obtaining written authorization from the customer before the subcontractor processes the data, whether through appropriate clauses in the customer contract or a specific one off agreement, holding a written contract with every such subcontractor that addresses implementation of the appropriate processor controls, requiring the subcontractor to implement them in light of the risk assessment and the scope of processing, with all such controls assumed relevant by default and any exclusion justified, responsibilities being allocable differently provided every control is considered and documented.

• Written customer authorization for each subcontractor, whether general or specific
• Written contract with every subcontractor carrying the processor control obligations
• Justification for any processor control not required of a subcontractor
• Evidence the risk assessment and processing scope informed which controls were required
• Reconciliation between subcontractors actually used and those authorized

• Subcontractor engaged on the strength of a general authorization that does not in fact cover it
• Subcontractor contracts carrying security terms while the processor control set is never flowed down
• Controls omitted by silence rather than justified exclusion
• Tooling and infrastructure providers that process personal data not recognised as subcontractors
• Authorization obtained once and not revisited when the subcontractor's scope of processing grew

Where it holds a general written authorization, the organization must inform the customer of any intended change involving the addition or replacement of a subcontractor that processes personal data, giving the customer the opportunity to object, and where it changes the subcontractor carrying out some or all of the processing, written authorization from the customer is required before the new subcontractor processes the data, whether through appropriate clauses in the customer contract or a specific one off agreement.

• Change notification procedure with the notice period and the objection route
• Records of notifications given and objections received, with outcomes
• Evidence that new subcontractors did not begin processing before authorization
• Contract terms establishing the general authorization and its conditions

• Notification given at the point of change or after, so the objection right is theoretical
• Objection received and overridden commercially with no record of the resolution
• Replacement subcontractor onboarded and processing during the notice period
• Notification published on a webpage the customer is expected to monitor rather than sent
• No notice period defined, so timely is whatever the organization decides

Scope note stating that this document sets out requirements and guidance for a privacy information management system built as an extension of ISO/IEC 27001 and ISO/IEC 27002, for any organization that processes personally identifiable information as a controller or a processor. It carries no obligation of its own.

• Nothing is auditable against this entry. It exists to orient the reader.
• Where scope is being evidenced, look instead to the PIMS scope statement produced under 5.2.3

• Treated as an auditable requirement in a Statement of Applicability, inflating the control count
• Cited as the source of an obligation that actually lives in clause 5, 7 or 8

Structural note recording that the document uses the common high level management system structure so that a privacy information management system can be integrated with other management systems the organization already runs. It carries no obligation.

• Nothing is auditable here. Integration evidence belongs with the management system documentation itself.
• Where integration is being evidenced, look to the combined management system manual

• Counted as a control, which distorts any coverage percentage computed over the framework
• Read as permission to merge PIMS records into ISMS records without keeping privacy decisions traceable

Structural note describing how the document is laid out, which clauses carry requirements against ISO/IEC 27001, which carry guidance against ISO/IEC 27002, and which annexes apply to a controller as against a processor. It carries no obligation.

• Nothing is auditable here.
• The role determination that decides which annex applies is evidenced under 5.2.1

• Mistaken for the role determination requirement, which is a genuine obligation elsewhere
• Counted in the denominator of a coverage figure

Locator table showing, for each management system clause of ISO/IEC 27001, where in this document the PIMS-specific requirements sit and where there are none. It is a navigation aid and carries no obligation.

• Nothing is auditable here.
• The extended reading of information security that the table depends on is evidenced under 5.1

• Read as meaning that clauses marked with no PIMS-specific requirements are out of scope, when the extended interpretation still applies to them
• Counted as a control

Locator table showing, for each control clause of ISO/IEC 27002, where in this document the PIMS-specific guidance sits and where the base guidance stands unchanged. It is a navigation aid and carries no obligation.

• Nothing is auditable here.
• The extended reading of information security that the table depends on is evidenced under 6.1

• Read as meaning that control areas with no PIMS-specific guidance need no privacy consideration
• Counted as a control

Definitional note fixing what the word customer means in this document, which differs according to whether the organization is a controller contracting with its own customer, a controller contracting a processor, or a processor contracting a subcontractor. It carries no obligation.

• Nothing is auditable here.
• Where the customer relationship is being evidenced, look to the contracts required under 7.2.6 or 8.2.1

• Customer read consistently as end consumer, which misreads every processor side obligation in clause 8
• Counted as a control

Every ISO/IEC 27002 guideline that speaks of information security must be read as extending to the protection of privacy affected by the processing of personally identifiable information, and every control objective and control must be considered against privacy risk as well as security risk, the same reading applying to controllers and processors unless a specific provision says otherwise.

• Documented adoption of the extended reading across the control set
• Control descriptions or a Statement of Applicability showing privacy risk was considered for each control
• Evidence the reading was applied to controls where this document adds nothing specific

• Extension applied only to the controls where clause 6 adds explicit guidance, leaving the majority judged on security alone
• Controller and processor guidance assumed to differ everywhere, when the same reading applies unless stated
• Extension declared in a policy and never carried into control design

Communications security must protect personal data in networks and in transfer, through network controls and through the policies, agreements and confidentiality terms that govern transfer.

• Network security controls covering segments carrying personal data
• Transfer policies, agreements and confidentiality terms
• Evidence of application

• Network controls designed on trust zones that do not reflect where personal data sits
• Transfer agreements in place with suppliers but not with group entities
• Confidentiality terms with no duration

Network controls, security in network services and segregation in networks apply as the base guidance requires, read as protecting the personal data that crosses those networks.

• Network control design and configuration evidence
• Network service agreements covering security
• Segregation evidence for segments carrying personal data

• Segregation designed once and eroded by later exceptions nobody reviewed
• Network services procured without security terms
• Flat internal networks giving broad reachability to data stores

Information transfer policies and procedures must include procedures ensuring that the rules governing the processing of personal data are enforced throughout and outside the system where applicable, and individuals operating under the organization's control with access to personal data must be under a confidentiality obligation whose duration is specified, a processor additionally ensuring that employees and agents comply with its data handling policy and procedures; transfer agreements and electronic messaging apply as the base guidance requires.

• Transfer policies and procedures showing how processing rules follow the data outside the system
• Signed confidentiality obligations for everyone with access to personal data, stating the duration
• Coverage of contractors and agents, not employees only
• Transfer agreements and messaging controls

• Rules enforced inside the application and lost the moment data is exported to a spreadsheet
• Confidentiality agreements with no stated duration, so the obligation is arguably spent at exit
• Agents and contractors relied on through the supplier's own terms, never verified
• Electronic messaging used to move personal data outside any transfer procedure

Systems acquisition, development and maintenance must build privacy in: security requirements for systems, privacy by design and by default through the development lifecycle, and protection of test data.

• Requirements, design and testing artefacts showing privacy considered
• Development policy covering privacy by design and by default
• Test data controls

• Privacy assessed at release rather than at design, when change is expensive
• Development policy naming privacy by design without saying what a developer must do
• Production personal data copied into test as a matter of routine

Security requirements analysis and specification and the protection of application services transactions apply as the base guidance requires, and personal data transmitted over untrusted networks, including the public internet and any facility outside the organization's operational control, must be encrypted for transmission.

• Requirements specifications covering privacy for new and changed systems
• Evidence of encryption for personal data crossing untrusted networks
• Definition of which networks the organization treats as untrusted
• Transaction protection evidence for application services

• Untrusted defined as the public internet only, leaving partner and third party links unencrypted
• Encryption terminated at a load balancer with the internal hop left in clear
• Requirements captured for security and silent on privacy obligations
• Legacy interfaces exempted indefinitely

System development and design policies must give guidance on the organization's processing needs based on its obligations to individuals and applicable law, covering privacy principles in the development lifecycle, privacy requirements at the design phase informed by risk or impact assessment, protection checkpoints at project milestones, the knowledge developers need, and minimising processing by default; systems and components processing personal data must be designed on privacy by design and privacy by default principles so collection and processing are limited to what the identified purposes need and so that later obligations such as timely disposal are facilitated; change control, technical review, package change restrictions, secure development environments, outsourced development and system and acceptance testing apply as the base guidance requires.

• Development policy carrying each of the required privacy by design elements
• Design artefacts showing privacy requirements derived from an impact assessment
• Evidence of privacy checkpoints at project milestones with outcomes
• Developer competence evidence for privacy knowledge
• Design evidence that systems facilitate later deletion and minimisation
• Outsourced development contracts carrying the same obligations

• Privacy by design asserted as a principle with no checkpoint that can stop a release
• Systems designed with no deletion path, so retention obligations become manual and unreliable
• Default settings that maximise collection, with minimisation available only if a user finds it
• Impact assessment produced after design is frozen, so it changes nothing
• Outsourced development held to security terms while privacy obligations stop at the organization's boundary

Personal data must not be used for testing; false or synthetic data must be used instead, and where using personal data for testing is unavoidable the technical and organizational measures of the production environment must be applied, with a risk assessment informing the choice of mitigating controls where equivalent measures are not feasible.

• Test data standard requiring synthetic or false data
• Where personal data is used, the authorisation, the equivalence of controls applied, and the risk assessment behind any shortfall
• Evidence of synthetic data generation capability
• Periodic check that test environments hold no unauthorised personal data

• Production data copied to test as the default because synthetic data generation was never built
• De-identification applied to obvious fields while free text and attachments retain identifying content
• Test environments protected below production while holding the same data
• No periodic sweep, so old production extracts persist in test long after the project ended

Supplier relationships must be governed by policy and agreements that carry the organization's privacy obligations down the chain, and by ongoing monitoring of what suppliers actually deliver.

• Supplier policy and agreements covering privacy
• Supplier register identifying which suppliers process personal data
• Monitoring and review evidence

• Supplier register that identifies spend but not who processes personal data
• Privacy terms signed at onboarding and never revisited
• Monitoring limited to service levels

Supplier agreements must state whether personal data is processed and the minimum technical and organizational measures the supplier must meet for the organization to satisfy its own security and privacy obligations, must clearly allocate responsibilities between the organization, its partners, suppliers and third parties according to the type of personal data processed, must provide a mechanism for supporting and managing compliance with applicable law, and must call for independently audited compliance acceptable to the customer; a processor must additionally specify in supplier contracts that personal data is processed only on its instructions. The supplier relationship policy and information and communication technology supply chain guidance apply as the base guidance requires.

• Supplier agreements stating whether personal data is processed and the minimum measures required
• Responsibility allocation matrix across the organization, partners, suppliers and third parties
• Compliance support mechanism written into the agreement
• Independent audit reports or certifications obtained and reviewed, not merely required
• Where the organization is a processor, contract terms limiting subcontractor processing to its instructions

• Agreements requiring appropriate measures without specifying any, which is unenforceable
• Independent audit called for in the contract and never collected or read
• Responsibility allocation absent, so obligations fall between the organization and its supplier
• Processor to subcontractor contracts silent on the instruction limitation, breaking the chain
• Supply chain assurance stopping at the first tier

Monitoring and review of supplier services and management of changes to those services apply as the base guidance requires, read as covering suppliers that process personal data.

• Supplier review records covering privacy performance
• Change notifications from suppliers and the assessment of each
• Evidence of action where a supplier fell short

• Reviews conducted on service levels with privacy obligations never tested
• Supplier changes accepted without assessment of the privacy consequences
• Findings raised with the supplier and never followed up

Incident management must recognise and handle breaches involving personal data, from responsibilities and identification through response, notification, recording, learning and evidence.

• Incident procedures naming personal data breaches
• Breach records and notification evidence
• Post incident learning records

• Breach handling treated as a subset of security incident handling with no notification path
• Records adequate for operations but not for a regulator
• Learning captured for technical causes only

The organization must establish responsibilities and procedures for identifying and recording breaches of personal data and for notifying required parties, including timing, and for disclosure to authorities under applicable law; an incident involving personal data must trigger a review to decide whether a breach requiring response has occurred, and where it has, response must include the relevant notifications and a record holding enough detail for regulatory or forensic reporting, including a description of the incident, its time period and consequences, who reported it, to whom, the steps taken to resolve it, whether personal data became unavailable, lost, disclosed or altered, what data was compromised and what notifications were made. A processor must have breach notification provisions in its customer contract specifying how it supplies the information the customer needs to notify

• Documented breach identification, recording and notification procedures with timings
• Evidence of the review step that decides whether an event is a notifiable breach
• Breach record template carrying every required field, and completed records or exercise output
• Where the organization is a processor, contract clauses on notification content and response times
• Notification records to authorities, customers or individuals where breaches occurred

• No decision step between event and breach, so either everything escalates or nothing does
• Notification timings written into procedure but never tested against a clock
• Breach records missing the description of what personal data was compromised, which is the field a regulator asks for first
• Processor contracts silent on notification content, so the controller cannot notify on time
• Notification treated as a legal task started after technical containment finishes, consuming the whole deadline

Continuity arrangements must keep protection of personal data in force during and after disruption, through planned, implemented and verified continuity of controls and through redundancy of processing facilities. This document adds no privacy specific guidance here beyond the extended reading of information security.

• Continuity arrangements covering the controls that protect personal data
• Redundancy evidence for processing facilities
• Verification and testing records

• Continuity planned for availability while protective controls lapse in the recovery environment
• Recovery site holding personal data under weaker controls than production
• Continuity of the privacy function itself never considered

Planning, implementing and then verifying, reviewing and evaluating information security continuity apply as the base guidance requires, read as keeping the protections around personal data in force through a disruption.

• Continuity plans covering the protective controls, not only the service
• Implementation evidence in the recovery environment
• Verification and evaluation records

• Continuity plans that restore the service and silently drop access control and logging
• Verification performed on failover but never on the control set
• Plans not updated after the control set changed

Availability of information processing facilities through redundancy applies as the base guidance requires, read as covering the facilities that process personal data.

• Redundancy design for facilities processing personal data
• Testing evidence
• Assessment that redundant copies are protected to the same standard

• Redundancy achieved by replicating personal data into a location whose controls were never assessed
• Redundant copies falling outside the retention and deletion regime
• Redundancy assumed from the provider with no evidence

Compliance must cover the identification of applicable law and contract, the protection of records, privacy of personal data and cryptographic regulation, and must be tested through independent and technical review.

• Legal and contractual requirements register
• Records protection and retention evidence
• Independent and technical review results

• Register covering security law while privacy obligations sit with a different team
• Reviews performed on policy conformance and never technically
• Findings not routed into the improvement process

Applicable legislation and contractual requirements must be identified, and the organization should identify the potential legal sanctions arising from missed obligations for the processing of personal data, including substantial fines from a supervisory authority and any contractual sanctions where this document forms the basis of a contract; the protection of records must extend to retaining copies of privacy policies and associated procedures, including superseded versions, for the period set in the retention schedule, since current and historical policies may need review in a dispute or a supervisory investigation. Intellectual property, privacy of personal data and cryptographic regulation apply as the base guidance requires.

• Register of applicable legislation and contractual requirements with the sanctions identified
• Retention schedule entry covering privacy policies and procedures
• Archive of superseded policy and procedure versions with effective dates
• Evidence the archive can reconstruct which policy governed a given processing activity at a given time

• Superseded policies overwritten, so the organization cannot show what rule applied when the disputed processing happened
• Sanctions unidentified, so the exposure behind a compliance gap is never quantified for management
• Register maintained for security law only
• Policy versions retained without effective dates, making reconstruction guesswork

Independent review of information security applies, and where the organization is a processor and individual customer audits are impractical or would increase risk, it should make available to customers, before and during a contract, independent evidence that security is implemented and operated to its policies and procedures, an independent audit normally being acceptable if it covers the needs of anticipated users and reports transparently; technical compliance review must include methods of reviewing the tools and components involved in processing personal data, which can include ongoing monitoring that only permitted processing occurs and specific penetration or vulnerability testing such as motivated intruder testing of de-identified datasets.

• Independent audit reports or certifications made available to customers before and during contract
• Assessment that the report's scope covers anticipated user needs
• Technical compliance review procedures covering tools and components that process personal data
• Evidence of monitoring that only permitted processing occurs
• Motivated intruder or equivalent testing results where de-identification is relied on

• Certification offered whose scope excludes the service the customer actually buys
• De-identification relied on as a legal position with no test that it resists re-identification
• Technical review covering infrastructure hardening while the processing logic goes unexamined
• Reports made available at sale and never refreshed during a multi year contract
• Monitoring that detects unauthorised access but not authorised access used for an unpermitted purpose

The policy layer must carry the organization's privacy position, either as separate privacy policies or by extending the information security policies, and must be reviewed on the same basis as any other policy.

• Policy set covering privacy, whether separate or extended
• Policy review records
• Evidence of communication and availability

• Privacy addressed in an external notice rather than in an internal policy
• Policies extended once and never reviewed against new legislation
• No allocation of responsibility between the organization and its partners

The organization must state, in separate privacy policies or by augmenting its information security policies, its support for and commitment to complying with applicable legislation and regulation on the protection of personally identifiable information and with the contractual terms agreed with partners, subcontractors and third parties, clearly allocating responsibilities between them; applicable legislation and regulation must be considered whenever those policies are developed or maintained.

• Policy text carrying an explicit commitment to applicable privacy legislation, regulation and contractual terms
• Responsibility allocation between the organization, partners, subcontractors and third parties
• Evidence that applicable legislation was consulted during policy development and at each maintenance cycle
• Policy review records with dates and approver

• Commitment stated to the law in general with no identification of which laws apply
• Responsibility allocation absent, so every party assumes another holds the obligation
• Policy maintained on a calendar cycle that ignores regulatory change
• Contractual privacy terms held in contracts but never reflected in policy

The organizational arrangements for information security must accommodate privacy: contact points for customers and individuals, an accountable privacy function, and the handling of mobile and remote working where personal data is involved.

• Organizational chart showing the privacy function and its reporting line
• Published contact points
• Mobile and teleworking arrangements addressing personal data

• Privacy function reporting into the team whose processing it is meant to challenge
• Contact point published externally but unmonitored
• Remote working policy silent on personal data

The organization must designate a contact point for the customer on matters of processing and, where it is a controller, a contact point for the individuals whose information it processes, and must appoint one or more persons responsible for an organization wide privacy governance programme who, where appropriate, are independent, report to an appropriate management level, are involved in all issues touching the processing of personal data, are expert in data protection law and practice, act as the contact for supervisory authorities, inform management and staff of their obligations, and advise on privacy impact assessments.

• Appointment record for the accountable privacy person or team, with the reporting line stated
• Terms of reference covering independence, involvement, expertise and the advisory role on impact assessments
• Published contact points for customers and for individuals
• Evidence the appointee was actually consulted on processing decisions and impact assessments
• Evidence of the appointee acting as the supervisory authority contact

• Appointment made in name only, with the person never consulted before a processing decision
• Independence compromised by reporting into the business function that owns the processing
• Expertise assumed rather than evidenced, most often where the role is added to a security manager's duties
• Contact point for individuals published on a channel different from the one used to collect their data
• Involvement limited to incidents, so design stage advice never happens

Mobile device and teleworking arrangements must be set so that using mobile devices does not lead to personal data being compromised.

• Mobile device policy addressing personal data specifically
• Technical controls on devices that hold or reach personal data
• Teleworking arrangements consistent with the same protection

• Mobile policy written for corporate data generally, with no consideration of personal data
• Personally owned devices reaching personal data outside any management regime
• Teleworking treated as an HR matter with no privacy assessment

Human resource security across the employment lifecycle must account for staff exposure to personal data, from screening and terms of employment through awareness and discipline to termination and role change.

• Screening, terms, awareness, discipline and termination records for roles with access to personal data
• Evidence the privacy dimension was considered in each

• Employment lifecycle controls applied uniformly with no regard to who touches personal data
• Role change treated as less significant than termination, leaving accumulated access in place

Screening and terms and conditions of employment must be applied as the base security guidance requires, read as covering the privacy exposure that the role carries.

• Screening records proportionate to the personal data the role will reach
• Employment terms carrying confidentiality and data handling obligations
• Records for contractors and agency staff on the same basis

• Screening depth set by seniority rather than by data access
• Contractors engaged without equivalent terms
• Terms silent on obligations that survive employment

During employment, management responsibilities, awareness and training, and disciplinary procedures apply, and awareness measures including incident reporting must ensure staff understand the consequences of breaching privacy or security rules for the organization, for themselves, and for the individuals whose data is involved.

• Awareness and training content covering consequences to the organization, to the staff member and to the individual
• Periodic training records for personnel with access to personal data
• Incident reporting instructions inside the awareness material
• Disciplinary procedure referencing privacy breaches

• Consequences framed as regulatory fines only, so staff never see the harm to the person behind the record
• Training delivered at induction and never repeated for staff who handle personal data daily
• Incident reporting route taught for security incidents but not for privacy breaches
• Disciplinary linkage asserted in policy but absent from the actual procedure

Responsibilities that survive termination or a change of employment must be defined and enforced, read as covering continuing obligations over personal data the person had access to.

• Termination and role change checklists covering access removal and continuing obligations
• Evidence obligations were communicated at exit
• Records for internal moves as well as departures

• Access removal handled but continuing confidentiality obligations never restated
• Internal role changes leaving accumulated access to personal data untouched
• Contractor offboarding handled by the supplier with no verification

Asset management must recognise personal data as an asset class: owned, inventoried, classified, labelled, handled and disposed of under rules that reflect what it is.

• Asset inventory reaching personal data holdings
• Classification scheme that names personal data
• Media handling and disposal rules applied to it

• Inventory covering systems but not the personal data inside them
• Classification scheme built on commercial sensitivity with no personal data dimension
• Media rules applied to backup tapes and not to removable devices in daily use

Assets must be inventoried, owned, used acceptably and returned on exit as the base guidance requires, with those obligations read as covering the personal data the assets hold.

• Asset inventory with named owners
• Acceptable use terms covering personal data
• Asset return records on exit

• Ownership assigned to a team rather than a person
• Shadow systems holding personal data absent from the inventory
• Return of assets evidenced for hardware but not for data copies

The information classification scheme must explicitly account for personal data, including its type and any special categories, so the organization knows what it processes, where it is stored and which systems it flows through, and the people under its control must be made aware of what personal data is and how to recognise it.

• Classification scheme with personal data and special categories named as classes
• Data map or flow documentation showing where each class is stored and how it moves
• Labelling guidance and evidence staff were told how to recognise personal data
• Awareness or competence records for the recognition training

• Classification scheme with confidential as its only relevant tier, which cannot distinguish personal data from commercial secrets
• Special categories not separated, so heightened obligations are invisible to the people handling the data
• Staff able to recite the classification labels but unable to identify personal data in front of them
• Storage and flow mapping stopping at the system boundary, missing exports and reports

Removable media use for personal data must be documented, encrypted wherever feasible with compensating controls where it is not, disposed of by secure procedures that leave the data inaccessible, and any physical transfer must be logged with media type, authorised sender and recipients, date, time and quantity, authorised before leaving the premises and protected so only the intended recipient can read it.

• Register of removable media used for personal data
• Encryption standard and evidence of application, with compensating controls documented where encryption was not feasible
• Secure disposal procedures and disposal records
• Physical media transfer log with type, authorised parties, date, time and count
• Authorisation records for media leaving the premises

• Removable media use prohibited by policy and practised anyway, so nothing is logged
• Unencrypted media used without recording why or what compensating control replaced encryption
• Disposal evidenced by a supplier certificate that does not identify the media disposed of
• Transfer logs recording despatch but not receipt, so loss in transit is undetectable
• Authorisation to remove media delegated to whoever is on shift

Access control must be governed, granted, exercised and technically enforced in a way that keeps access to personal data limited to those authorised and attributable to individuals.

• Access control policy covering personal data
• Provisioning, review and revocation records
• Technical enforcement evidence

• Access policy that governs systems but never data categories
• Shared accounts on systems holding personal data, destroying attribution
• Reviews performed on the account list rather than on what the accounts can reach

The access control policy and the rules for access to networks and network services apply as the base guidance requires, read as governing access to personal data.

• Access control policy referencing personal data as a governed class
• Network and service access rules
• Evidence the policy drives actual entitlement design

• Policy written at the level of systems, so personal data access is inherited rather than granted
• Network access rules that permit broad internal reachability to data stores
• Policy and implemented entitlements never reconciled

User registration and deregistration for people who administer or operate systems processing personal data must address compromise of their access credentials, deactivated or expired user identifiers must never be reissued for those systems, and the organization must keep an accurate current record of authorised user profiles so that access to personal data and any additions, deletions or changes can be attributed to a person; where the organization processes personal data as a service, any customer responsibility for identity or access management must be documented and the means to exercise it provided.

• Registration and deregistration procedures covering credential compromise
• Evidence that identifiers on systems processing personal data are never reissued
• Current user profile record supporting attribution of access and change
• Documented split of identity and access management responsibility with customers, and the administrative means provided to them
• Access review records

• Identifiers reissued to new joiners, so historical access records point at the wrong person
• Attribution impossible because operations run through a shared service account
• Customer responsibility for access management assumed but never written down, so neither party performs it
• Credential compromise handled as a security incident with no consideration of the personal data exposed
• Profile records maintained at creation and never on change

Users must meet their own responsibilities for protecting authentication information as the base guidance requires, read as protecting the personal data that their credentials unlock.

• Acceptable use and authentication terms accepted by users
• Awareness content on credential protection
• Evidence of enforcement where terms were breached

• Terms accepted at induction and never refreshed
• Credential sharing tolerated in operational teams
• No consequence applied when sharing is discovered

System and application access control must restrict access to information, provide secure log on, manage passwords, constrain privileged utilities and protect source code, and where the customer requires it the organization must provide secure log on capability for user accounts under that customer's control.

• Access restriction configuration for applications holding personal data
• Secure log on mechanisms, including any capability offered to customers for accounts they control
• Password management and privileged utility controls
• Source code access controls
• Record of customer requirements for log on capability and how they were met

• Application level restriction absent, so any authenticated user reaches every record
• Customer facing accounts left on weaker authentication than internal ones
• Privileged utilities available to operators who need no such access to personal data
• Customer requirement for secure log on captured in a sales document and never implemented

Cryptographic controls must be governed by a policy that accounts for personal data, and the keys behind them managed through their lifecycle.

• Cryptographic policy naming personal data
• Key management procedures
• Evidence of application to systems holding personal data

• Policy that mandates encryption without saying for what data or at what state
• Keys managed by the same administrators who can read the data
• Encryption in transit assumed to satisfy encryption at rest

The policy on the use of cryptographic controls must take account of jurisdictions that require cryptography for particular categories of personal data such as health data or national identifiers, the organization must tell the customer in what circumstances it applies cryptography to the personal data it processes, and must tell the customer about any capability it offers to help the customer apply cryptography of its own; key management applies as the base guidance requires.

• Cryptographic policy referencing jurisdiction specific mandates for categories of personal data
• Documentation issued to customers describing where cryptography is applied and to what
• Description of customer facing cryptographic capabilities such as customer managed keys
• Key management procedures covering generation, storage, rotation, escrow and destruction

• Jurisdictional cryptography mandates unmapped, so a category of data crosses into a jurisdiction that requires more than is applied
• Customer told that data is encrypted with no statement of what that covers, leaving a false impression
• Customer managed key capability offered without documenting the recovery consequences
• Key destruction never performed, so cryptographic erasure cannot be relied on

Physical and environmental security must protect the places and equipment where personal data is held, including the reuse and disposal of storage and the exposure of data in working areas.

• Physical protection for locations holding personal data
• Equipment lifecycle controls including disposal and reuse
• Clear desk and clear screen enforcement

• Physical controls scoped to the data centre while personal data is printed and left in offices
• Disposal handled by a supplier whose certificates are never checked
• Third party sites in scope of processing but not of physical assessment

Secure area controls covering the security perimeter, entry, offices and facilities, protection against external and environmental threats, working in secure areas and delivery and loading areas apply as the base guidance requires, read as protecting the personal data those areas contain.

• Perimeter and entry control evidence for areas holding personal data
• Working practices for secure areas
• Delivery and loading area controls

• Secure area designation applied to server rooms only, leaving records storage unclassified
• Entry logs kept but never reviewed
• Delivery areas providing an unescorted route past areas holding personal data

Equipment controls apply across siting, utilities, cabling, maintenance, removal and off premises use, and additionally the organization must ensure that reassigned storage space leaves no accessible personal data behind, must use specific technical measures where explicit erasure is impractical, must treat any equipment whose media could hold personal data as though it does, and must restrict the creation of hardcopy containing personal data to the minimum the identified purpose requires.

• Storage reassignment procedure with evidence that residual data is not accessible
• Technical measures documented where explicit erasure is impractical, such as cryptographic erasure
• Disposal and reuse procedure treating suspect media as containing personal data
• Hardcopy minimisation rules and clear desk enforcement evidence
• Equipment maintenance and off premises use records

• Virtualised or cloud storage reassigned with reliance on the provider and no assurance obtained
• Deletion treated as erasure, leaving data recoverable by the next tenant of the storage
• Media of unknown content disposed of as clean because nobody checked
• Hardcopy minimisation stated in policy while reports containing personal data print on a schedule
• Equipment sent for repair with storage still installed

Operations security must run the day to day processes that keep personal data protected: documented procedures, change and capacity management, environment separation, malware protection, backup, logging, software control, vulnerability management and audit considerations.

• Operating procedures covering systems that process personal data
• Evidence of operation across change, backup, logging and vulnerability management
• Environment separation evidence

• Procedures documented for the platform but not for the personal data handling steps
• Production data used to populate test environments
• Operational evidence collected only where a tool produces it automatically

Operating procedures must be documented, change managed, capacity managed, and development, test and operational environments kept separate, read as covering the systems that process personal data.

• Documented operating procedures for personal data processing systems
• Change records covering those systems
• Evidence of separation between development, test and operational environments

• Procedures maintained for infrastructure while application level data handling is tribal knowledge
• Environments separated logically but sharing the same data
• Emergency change route that bypasses the privacy consideration

Controls against malware apply as the base guidance requires, read as protecting the personal data that a compromise would expose.

• Malware protection coverage across systems holding personal data
• Detection and response records
• Evidence of coverage on endpoints that hold local copies

• Coverage measured against the asset inventory, which omits systems holding personal data
• Detections handled without considering whether personal data was exposed
• Servers excluded on performance grounds with no compensating control

The organization must hold a policy covering backup, recovery and restoration of personal data and any further contractual or legal requirements for erasing personal data held in backups, must tell the customer the limits of the service and, where it provides backup and restore, describe its capabilities, must meet jurisdiction specific requirements on backup frequency, testing and recovery, must ensure restored personal data is returned to a state where its integrity can be assured with inaccuracy or incompleteness identified and resolved, and must keep a procedure and a log of restoration efforts recording at minimum who was responsible and what personal data was restored.

• Backup policy addressing personal data specifically, including erasure obligations within backups
• Statement to customers of backup service limits and capabilities
• Restoration procedure and a restoration log naming the responsible person and describing the data restored
• Evidence of integrity assurance following restoration, including how inaccuracy is identified and resolved
• Evidence of compliance with jurisdiction specific backup and recovery requirements

• Erasure performed in production while backups retain the same personal data indefinitely, defeating deletion obligations
• Restoration performed with no log, so nobody can say whose data was reinstated
• Restored data reintroducing records the individual had already had erased
• Customer left to assume backup coverage that the service does not provide
• Backup testing evidenced as a successful job rather than a successful restoration

Event logs must be reviewed by continuous automated monitoring or by manual review at a documented frequency to find irregularities and propose remediation, logs must where possible record access to personal data including who accessed it, when, whose data it was and what changes resulted, roles must be defined and agreed where several providers share the logging duty, log information that itself contains personal data must be access controlled so it is used only as intended and deleted or de-identified per the retention schedule, and a processor must define and publish to customers the criteria for making log information available while ensuring one customer can never read or amend another's records; protection of logs, administrator and operator logs and clock synchronization apply as the base guidance requires.

• Documented log review process with the frequency stated, or evidence of automated monitoring and alerting
• Log schema evidencing capture of who, when, whose data and what change
• Access controls over log stores and evidence logs are deleted or de-identified per the retention schedule
• Documented allocation of logging roles where multiple providers are involved, with any log access agreement
• Where customers can read logs, evidence of tenant isolation and immutability

• Logs generated and never reviewed, so the control produces evidence for an investigation that nobody starts
• Access logging at system level only, so it is impossible to say whose personal data was read
• Log stores excluded from the retention schedule, quietly becoming the longest lived copy of the personal data
• Customer log access implemented without isolation, exposing one customer's activity to another
• Shared responsibility for logging left undefined between providers, so neither retains what is needed

Control over the installation of software on operational systems applies as the base guidance requires, read as protecting systems that process personal data from unreviewed change.

• Installation control procedure for operational systems
• Records of approved installations
• Detection of unauthorised software

• Control applied to servers while endpoints holding personal data are unmanaged
• Approval evidenced by a change ticket that carries no privacy consideration
• No detection, so unauthorised installation is discovered only by accident

Technical vulnerability management and restriction on software installation apply as the base guidance requires, read as protecting the personal data that an unpatched vulnerability would expose.

• Vulnerability management process with timescales
• Evidence of coverage over systems holding personal data
• Remediation records and exception approvals

• Remediation prioritised on technical severity with no weighting for personal data exposure
• Coverage gaps on systems that the asset inventory misses
• Exceptions granted indefinitely without review

Information systems audit controls apply as the base guidance requires, so audit activity on operational systems is planned and agreed to minimise disruption, read as covering systems that process personal data.

• Agreed audit procedures for operational systems
• Records of audit access granted and its scope
• Evidence audit tooling access to personal data was itself controlled

• Audit tooling granted standing broad access to production data
• Audit activity performed without agreement, disrupting processing
• Auditor access never revoked after the engagement

Every requirement of ISO/IEC 27001 that speaks of information security must be read as extending to the protection of privacy as it may be affected by the processing of personally identifiable information, so the management system is judged against privacy risk as well as security risk throughout.

• Documented statement adopting the extended interpretation across the management system
• ISMS documentation revised so that security scoped statements now cover privacy
• Evidence the extension reached risk criteria, objectives and audit scope, not only the policy

• Extension declared in the policy and nowhere else, so risk assessment and audit still test security only
• Privacy managed as a parallel system rather than as an extension, producing two registers that disagree
• Clauses that carry no PIMS-specific requirement treated as unaffected by the extension

The context clauses of ISO/IEC 27001 gain additional requirements under a PIMS: the organization's role in relation to personally identifiable information, the privacy specific factors bearing on its context, the interested parties attached to that processing, and the inclusion of the processing itself within scope.

• Documented role determination and privacy context analysis
• Interested party register extended to privacy stakeholders
• PIMS scope statement covering the processing of personally identifiable information

• Context inherited unchanged from the ISMS with no privacy factors added
• Role never determined, so the applicable annex is chosen by assumption
• Scope silent on processing activities, which leaves coverage unprovable

The organization must determine its role as a controller, joint controller or processor, and must determine the external and internal factors bearing on its ability to achieve the intended outcomes of the PIMS, including applicable privacy legislation, regulation, judicial and administrative decisions, organizational governance and contractual requirements; where it acts in both roles, the roles must be separated and each made the subject of its own set of controls.

• Documented role determination per processing activity, not merely per organization
• Register of applicable privacy legislation, regulation and decisions
• Contractual requirements bearing on privacy, extracted and recorded
• Where both roles are held, separate control sets with the boundary between them documented

• A single organization wide role declared, when the role changes by processing activity
• Dual role organizations running one blended control set, so processor duties and controller duties are never separately provable
• Context limited to the home jurisdiction while processing crosses borders
• Judicial and supervisory authority decisions omitted from the legal landscape

The interested parties of the management system must be extended to include everyone with an interest or responsibility in the processing of personally identifiable information, expressly including the individuals whose information is processed.

• Interested party register naming data subjects, customers, supervisory authorities, other controllers, processors and subcontractors
• The requirement recorded against each of those parties
• Evidence the register is maintained as processing relationships change

• Data subjects omitted from the register, which is the omission the clause exists to prevent
• Supervisory authorities treated as a compliance matter rather than an interested party of the system
• Subcontractors of processors left off entirely

When determining the scope of the PIMS, the organization must bring the processing of personally identifiable information inside it, which may in turn require the existing information security management system scope to be revised.

• PIMS scope statement expressly covering processing activities
• Record of any consequential revision to the ISMS scope
• Reconciliation between the processing inventory and the declared scope

• PIMS scope copied from the ISMS scope with no processing added
• Processing carried out by an in scope entity but on out of scope systems, leaving a gap nobody owns
• ISMS scope left unrevised, so the two scopes contradict each other

The organization must establish, implement, maintain and continually improve a privacy information management system that satisfies the management system clauses of ISO/IEC 27001 as extended by the PIMS-specific requirements of this document.

• PIMS documentation showing the ISO/IEC 27001 clauses and the PIMS extensions together
• Evidence of operation across a full management cycle
• Improvement record specific to the privacy extension

• PIMS asserted as an ISMS with a privacy annex bolted on, with no evidence the management clauses were re run
• Continual improvement evidenced only for security topics
• Extensions documented but never operated

Leadership over the PIMS is the leadership ISO/IEC 27001 already requires, exercised over a system whose subject matter now includes privacy risk to the individuals whose information the organization processes.

• Evidence top management engagement covers privacy, not security alone
• Policy, roles and commitment artefacts showing the extended subject matter

• Leadership evidence drawn entirely from security governance forums that never discuss privacy
• Privacy delegated to a specialist with no top management line of sight

Top management must demonstrate the leadership and commitment ISO/IEC 27001 requires, with every reference to information security read as covering privacy risk arising from the processing of personally identifiable information.

• Governance minutes showing privacy matters decided at top management level
• Resource decisions covering the privacy programme
• Evidence privacy objectives were aligned with strategic direction

• Privacy items appearing on the governance agenda only after an incident
• Commitment evidenced through the security steering group, which has no privacy remit
• Privacy programme funded below the level its own risk assessment calls for

The policy requirements of ISO/IEC 27001 apply to the PIMS, meaning the policy set must commit the organization on privacy as well as on information security under the extended interpretation.

• Policy set, whether a single extended policy or a separate privacy policy, approved and current
• Communication and availability records
• Traceability from policy commitments to privacy objectives

• Security policy left untouched and a privacy notice offered in its place, which is a customer facing document rather than a policy
• Two policies that contradict each other on retention or disclosure
• Policy never reissued after the role determination changed

Organizational roles, responsibilities and authorities must be assigned and communicated as ISO/IEC 27001 requires, now covering the privacy responsibilities that the extended interpretation brings into the management system.

• Responsibility assignment covering privacy roles and their authority
• Evidence of communication to the holders
• Reporting line from the privacy role into top management

• Privacy responsibility assigned without the authority to stop a processing activity
• Roles assigned to a function rather than a person, so nobody answers for them
• No deputy, leaving the privacy function unavailable during absence

Planning under the PIMS keeps the ISO/IEC 27001 requirements for risks and opportunities and objectives, with risk assessment and risk treatment refined so that privacy risk to individuals is assessed alongside information security risk and treated against the PIMS control annexes.

• Risk methodology covering both security and privacy risk
• Risk treatment records referencing the applicable PIMS annex
• Objectives covering the privacy extension

• Privacy risk assessed only as risk to the organization, never as risk to the individual
• Treatment compared against the ISMS annex alone, so PIMS controls are never tested for omission
• Objectives unchanged from the ISMS set

The actions to address risks and opportunities gain PIMS refinements: the risk assessment must identify privacy risks arising from processing as well as confidentiality, integrity and availability risks, must assess consequences for the individual as well as for the organization, and the treatment must be checked against the PIMS control annexes with a Statement of Applicability that justifies every inclusion and exclusion.

• Documented risk assessment process addressing security risk and privacy risk and the relationship between them
• Risk records showing consequences assessed for the individual as well as for the organization
• Statement of Applicability covering the PIMS annex applicable to the determined role, with justification for each inclusion and exclusion
• Evidence the treatment comparison actually tested for omitted controls

• Consequence assessed as organizational impact only, with the individual absent from the scoring
• Statement of Applicability covering the ISMS annex alone, so PIMS controls are neither included nor excluded, merely missing
• Exclusions asserted without justification, or justified by a risk assessment that never considered the control
• Security and privacy risk assessed in isolation, so the relationship between them is managed by nobody

The requirements of ISO/IEC 27001 for setting information security objectives and planning to achieve them apply to the PIMS, with those objectives now reaching privacy outcomes under the extended interpretation.

• Objective register including privacy objectives with measures and owners
• Plans showing what will be done, by whom, by when and how evaluated
• Monitoring results against the privacy objectives

• Objective set carried over from the ISMS with no privacy objective added
• Privacy objectives expressed as compliance with the law, which is not measurable
• Objectives set but never monitored

The support clauses of ISO/IEC 27001, covering resources, competence, awareness, communication and documented information, apply to the PIMS with their subject matter extended to privacy.

• Support artefacts across all five areas showing privacy coverage
• Evidence the extension is operational rather than declared

• Support processes inherited from the ISMS with no privacy content added
• Documented information controls that do not contemplate privacy records such as consent or transfer logs

The organization must determine and provide the resources needed to establish, implement, maintain and improve the PIMS, which under the extended interpretation includes what the privacy side of the system requires.

• Documented resource determination for the PIMS
• Evidence of provision such as budget, headcount or contracted expertise
• Escalation record where resourcing fell short

• Privacy resourced from spare security capacity
• Specialist legal capability assumed available and never contracted
• Resource need never separately determined for the privacy extension

The competence requirements of ISO/IEC 27001 apply to the PIMS, so the organization must determine, ensure, act on and evidence the competence of people whose work affects privacy performance as well as security performance.

• Competence profile for privacy roles
• Evidence of education, training or experience per role holder
• Gap actions with an evaluation of effectiveness
• Retained competence records

• Security competence records reused for privacy roles that need legal and regulatory knowledge
• Competence assumed from job title
• Actions taken but never evaluated

The awareness requirements of ISO/IEC 27001 apply to the PIMS, so people working under the organization's control must be aware of the policy, of their contribution, of the consequences of non conformity and of their role, read as covering privacy.

• Awareness material covering privacy obligations and individual responsibilities
• Delivery records including contractors and new starters
• A check that awareness landed, not merely that it was delivered

• Privacy awareness folded into annual security training as a single slide
• Consequences to the individual whose information is processed never mentioned
• Contractors with access to personal data excluded

The communication requirements of ISO/IEC 27001 apply to the PIMS, so the organization must determine what privacy relevant communication is needed internally and externally, when, with whom, how and by whom.

• Communication plan covering privacy topics and audiences
• Named authority for external privacy communication including with supervisory authorities
• Evidence the plan has been exercised or used

• No named channel to the supervisory authority until a breach forces one
• Communication plan covers security incidents only
• Communication with individuals conflated with marketing channels

The documented information requirements of ISO/IEC 27001 apply to the PIMS across creation, updating and control, so privacy records fall under the same identification, approval, availability, protection and retention discipline as security records.

• Document register covering privacy records such as processing inventories, consent records and transfer logs
• Creation, update and approval route applied to those records
• Access, retention and disposition rules applied to them

• Privacy records held outside document control, most often consent evidence in a marketing system
• Retention rules applied to documents but not to the personal data inside them
• Records of external origin such as processor contracts left uncontrolled

The operation clauses of ISO/IEC 27001, covering operational planning and control and the running of risk assessment and risk treatment, apply to the PIMS with privacy risk inside their subject matter.

• Operational control evidence covering privacy processes
• Risk assessment and treatment performed on the planned cycle with privacy in scope

• Operational processes documented for security only
• Risk assessment performed at planning time and never re run in operation

The operational planning and control requirements of ISO/IEC 27001 apply to the PIMS, so the processes that deliver privacy outcomes must be planned, implemented, controlled against criteria and evidenced, with changes controlled and outsourced processing controlled.

• Process criteria for privacy relevant operational processes
• Records showing those processes ran to their criteria
• Change records covering privacy affecting change
• Evidence of control over outsourced processing

• Outsourced processing controlled by contract alone with no verification
• No criteria, so operational control cannot be demonstrated
• Changes to processing purposes made without a control gate

The requirement of ISO/IEC 27001 to perform risk assessments at planned intervals or on significant change applies to the PIMS, so privacy risk assessment is a recurring operation rather than a one time planning exercise.

• Schedule of risk assessments with evidence of execution
• Trigger definition for significant change
• Retained assessment results including privacy risk

• Assessment run once at implementation and never repeated
• Significant change undefined, so the trigger never fires when a new processing activity starts
• Results not retained, so no trend is visible

The requirement of ISO/IEC 27001 to implement the risk treatment plan applies to the PIMS, so the privacy controls chosen during treatment must actually be implemented and their implementation evidenced.

• Risk treatment plan with implementation status per control
• Evidence of implementation for the privacy controls selected
• Residual risk acceptance records

• Treatment plan closed on the basis that a control was purchased rather than operating
• Privacy controls in the Statement of Applicability with no implementation evidence
• Residual risk accepted by someone without the authority to accept it

The performance evaluation clauses of ISO/IEC 27001, covering monitoring and measurement, internal audit and management review, apply to the PIMS with privacy performance inside what is measured, audited and reviewed.

• Measurement, audit and review artefacts each showing privacy coverage
• Evidence privacy findings reach the same governance forum as security findings

• Privacy excluded from the internal audit programme
• Management review pack with no privacy performance information

The monitoring, measurement, analysis and evaluation requirements of ISO/IEC 27001 apply to the PIMS, so the organization must determine what privacy performance is measured, by what valid method, when and by whom, and must evaluate the results.

• Measurement set covering privacy performance with method, frequency and owner
• Retained results
• Evaluation of PIMS effectiveness drawn from those results

• Privacy measured by counting requests received rather than by whether obligations were met on time
• Measurement collected and never analysed
• Method changed between periods, destroying the trend

The internal audit requirements of ISO/IEC 27001 apply to the PIMS, so internal audit must test conformity and effective implementation of the privacy extension as well as of the security management system.

• Audit programme covering PIMS clauses and the applicable control annex
• Audit reports addressing privacy conformity and effectiveness
• Auditor independence and competence evidence for privacy subject matter
• Findings tracked to closure

• Audit scope inherited from the ISMS, so PIMS clauses are never sampled
• Auditors competent in security auditing a legal and regulatory subject they do not know
• Findings raised against documentation existence rather than operating effectiveness

The management review requirements of ISO/IEC 27001 apply to the PIMS, so top management must review the privacy extension at planned intervals against the same defined input set and record the resulting decisions.

• Review records showing privacy inputs presented and privacy decisions taken
• Attendance evidencing top management
• Actions arising tracked to closure

• Privacy noted as an agenda item with no input data behind it
• Review conducted by the privacy function reporting to itself
• Decisions recorded without owners or dates

The improvement clauses of ISO/IEC 27001, covering nonconformity and corrective action and continual improvement, apply to the PIMS so that privacy failures are analysed to cause and the privacy extension keeps improving.

• Nonconformity and improvement records covering privacy
• Evidence of improvement in the privacy extension over successive cycles

• Privacy nonconformities handled as incidents and closed without root cause
• Improvement evidenced only where something had already failed

The nonconformity and corrective action requirements of ISO/IEC 27001 apply to the PIMS, so a privacy nonconformity must be reacted to, its cause evaluated and eliminated, similar occurrences checked for, the corrective action reviewed for effectiveness, and the whole retained as documented evidence.

• Nonconformity register including privacy findings from audit, incident and complaint
• Root cause analysis and extent of condition check
• Corrective action with effectiveness review
• Retained evidence of the nonconformity and the outcome

• Individual complaints resolved one by one with the systemic cause never examined
• Extent of condition never checked, so the same defect persists in a sister processing activity
• Effectiveness review omitted, so recurrence is the only test the fix receives

The continual improvement requirement of ISO/IEC 27001 applies to the PIMS, so the organization must keep improving the suitability, adequacy and effectiveness of the privacy extension and not only correct it when it fails.

• Improvement backlog with privacy items traceable to measurement, audit or review
• Evidence of improvements delivered across cycles
• Link from regulatory and business change into the improvement determination

• Improvement register that only ever contains corrective actions
• Regulatory developments tracked by legal but never entering the improvement process
• Backlog that accumulates and never closes