GDPR and security: connect safeguards to processing

A well-run information security management system provides useful processes for GDPR: access management, incident handling, supplier assessment, and resilience. Privacy work also asks why processing is lawful, proportionate, and transparent. Those questions meet in the same business activity, but they require different decisions.

For leadership, the task is to connect them without treating one as a substitute for the other. A secure customer database can still contain information the company should not have collected. A valid customer contract does not establish that everyone with database access needs that access. An ISO 27001 certificate does not resolve either question.

The practical starting point is therefore processing, not a catalogue of controls. Identify what the business wants to do with personal data, assess whether that activity is permissible, and then select safeguards for the consequences of failure. Preserve the reasoning, the evidence, the responsible owner, and the next event that should trigger review.

Establish which processing and responsibilities are in scope

The General Data Protection Regulation regulates processing of personal data. Processing includes collection, storage, consultation, disclosure, alteration, and deletion. Personal data is information relating to an identified or identifiable natural person; it is not limited to names or obviously sensitive records.

Business email addresses, employee identifiers, device identifiers, location histories, and support conversations may all be personal data. Whether a particular identifier qualifies depends on the context and the means reasonably likely to be used to identify someone. Replacing names with reference numbers normally produces pseudonymised data, not anonymous data, when reidentification remains possible. Pseudonymised personal data remains within GDPR.

Check territorial reach before choosing an operating model

Article 3 covers processing in the context of an EU establishment, even where the processing itself takes place elsewhere. It can also cover an organisation outside the EU when its processing relates to offering goods or services to people in the Union or monitoring their behaviour there. Website accessibility alone does not settle the targeting question; assess the actual offering and monitoring activity.

Where Article 3(2) applies, Article 27 can require a representative in the Union. Its exemptions are limited and do not depend simply on company size. The occasional-processing exemption also requires the specified conditions concerning sensitive data and risk. A representative is not a replacement for the controller, a DPO, or accountable management.

The GDPR entered into force on 24 May 2016 and has applied since 25 May 2018. For present decisions, distinguish the law in force from proposed simplifications. A press release about a possible exemption is not a basis for stopping an existing compliance process.

Determine roles by activity, not by company label

A controller determines the purposes and means of processing. A processor processes personal data on a controller's behalf. Joint controllers jointly determine purposes and means and need an Article 26 arrangement reflecting their respective responsibilities.

One company can occupy several roles. A software provider may be a processor for customer-uploaded records and a controller for its own payroll, account administration, and some security operations. A supplier's contract label is relevant, but cannot override what the parties actually do.

The initial deliverable should be a short scope decision: applicable activities, organisational entities, controller or processor roles, markets, and unresolved questions. Assign an owner to resolve uncertainties before the related processing begins or expands.

Separate the business purpose from the legal basis

Articles 5 and 6 establish the foundation for ordinary personal-data processing. Security is one part of that foundation, not a route around it.

The Article 5 principles are commonly presented as seven: lawfulness, fairness and transparency; purpose limitation; data minimisation; accuracy; storage limitation; integrity and confidentiality; and accountability. Accountability requires the controller to be responsible for, and able to demonstrate, compliance. It does not require a particular software product, but it does require a defensible explanation supported by appropriate evidence.

Translate each principle into a business question:

Choose a basis for each purpose

Article 6 provides six legal bases. Their conditions matter more than their labels:

• Consent: a freely given, specific, informed, and unambiguous indication of agreement, with withdrawal possible.
• Contract: processing necessary to perform a contract with the individual or take requested pre-contractual steps.
• Legal obligation: processing necessary to comply with an applicable legal obligation.
• Vital interests: processing necessary to protect someone's vital interests.
• Public task: processing necessary for a task in the public interest or the exercise of official authority, with the required legal foundation.
• Legitimate interests: processing necessary for legitimate interests, subject to the balancing of those interests against the individual's interests, rights, and freedoms.

Do not list several bases as interchangeable insurance. Establish the basis that actually supports each purpose and communicate it accurately. Adding a term to a customer contract does not automatically make processing necessary for that contract. Similarly, legitimate interests requires an assessment; it is not a general permission to use available data.

As a practical recommendation, document a legitimate-interests assessment around the interest pursued, necessity, effects on people, their reasonable expectations, and safeguards. Consider less intrusive alternatives. Keep the analysis proportionate to the activity, but specific enough for someone outside the project to understand it.

Consent is not universally safer. It must be genuinely optional where the circumstances require choice, and withdrawal must work in practice. Employment relationships raise particular concerns about whether agreement is freely given. Withdrawal ends processing based on that consent going forward; it does not automatically erase records subject to separate lawful retention duties. Do not retrospectively switch the same processing to another basis merely because consent has been withdrawn. Any separate processing, such as legally required retention, needs its own applicable basis and appropriate transparency.

Special-category data, such as health information, needs an Article 9 condition as well as an Article 6 basis. Criminal-conviction and offence data has separate Article 10 requirements. A company should not approve either category merely because ordinary customer processing has already been assessed.

Build a processing record that can drive decisions

Article 30 records of processing activities are useful because they connect legal analysis to operational reality. A controller's record includes purposes, categories of individuals and data, recipients, transfers, envisaged erasure time limits where possible, and a general description of security measures where possible. Processors have a different record obligation covering the processing they carry out on behalf of controllers.

The fewer-than-250-employees exemption is conditional. It does not cover processing that is not occasional, is likely to create the specified risk, or includes the specified sensitive categories. A small business with ongoing employee or customer processing should not assume that headcount removes its record obligations.

Use processing activities as the organising unit. “Cloud infrastructure” is usually too broad to explain why data is processed. “Managing customer support requests” is more useful because it has a purpose, identifiable people, data categories, recipients, retention rules, and supporting systems.

A practical working record can go beyond the statutory fields:

• Business owner and privacy reviewer.
• Purpose and relevant legal basis.
• Data sources, categories, and affected groups.
• Controller, processor, or joint-controller relationships.
• Applications, exports, logs, and downstream recipients.
• Retention rules and how deletion is executed.
• Notice, rights-handling, supplier, and transfer references.
• DPIA screening result and linked safeguards.
• Approval date, unresolved actions, and review triggers.

The additional fields are a recommendation for coordination, not a claim that Article 30 expressly requires every item. Their value is that they make the record usable during a launch, access request, supplier change, or incident.

Reconcile the record with the systems people actually use

An annual questionnaire is unlikely to reveal every spreadsheet export, trial application, or team-level AI subscription. Compare the record with procurement information, approved application lists, system inventories, and interviews with process owners. Review shared drives and manual handoffs where they materially affect the activity.

Do not confuse an asset inventory with a processing record. The asset inventory explains systems and dependencies; the processing record explains uses of personal data. Connect them so one application can support several purposes without merging those purposes into an indistinct description.

For additional workflow context, see data discovery and privacy. Discovery should produce a reviewable list of discrepancies, not an assumption that every detected field has been correctly classified or legally assessed.

Translate Article 32 into safeguards for real consequences

Article 32 GDPR requires controllers and processors to implement technical and organisational measures appropriate to risk. The assessment considers the state of the art, implementation costs, the nature, scope, context and purposes of processing, and the likelihood and severity of risks to people's rights and freedoms.

The relevant consequences include accidental or unlawful destruction, loss, alteration, unauthorised disclosure, and unauthorised access. This makes availability and integrity important alongside confidentiality. Losing access to a service can harm people even when no data has been stolen.

A generic statement that “industry-standard security applies” is not enough to explain why safeguards fit a particular activity. Start with scenarios: who could be affected, what could happen, how likely it is, and how severe the effect could be. Then connect each important scenario to preventive, detective, and recovery measures.

Access restrictions should follow the purpose

For a support activity, ask which agents need which customer records, whether sensitive attachments need separate restrictions, and when temporary access should expire. Consider privileged administration, supplier support access, bulk exports, shared accounts, and emergency access.

Useful evidence includes role definitions, access approvals, joiner-mover-leaver records, privileged-access arrangements, and completed access reviews. An access policy proves an intended rule. A recent review showing unnecessary permissions removed provides evidence that the rule is being operated.

Leadership should ask whether the organisation can distinguish authorised access from appropriate use. An employee may have a technically valid account yet use data for an unauthorised purpose. Training, supervision, access design, and investigation processes all matter.

Encryption requires a deployment decision

Article 32 identifies encryption and pseudonymisation among measures to consider; it does not impose a universal blanket encryption mandate for every situation. Where encryption is selected, specify what it protects and what it does not.

Encryption in transit protects data travelling between endpoints when the protocols and endpoint authentication are properly configured. Encryption at rest protects stored data under particular threat scenarios. Neither automatically prevents an authorised application or administrator from seeing plaintext.

Review who controls keys, how access to them is separated, and how keys are generated, rotated, revoked, backed up, and recovered. Provider-managed encryption may be appropriate for some risks while leaving others unresolved. Encryption whose keys are available to the same compromised actor may not address the scenario being assessed.

The executive decision is not which algorithm to implement personally. It is whether the design addresses the relevant risk and whether the technical owner can substantiate that conclusion. See encryption and key management for the control-level distinctions.

Resilience must be demonstrated, not assumed

Article 32 addresses ongoing confidentiality, integrity, availability, and resilience, along with the ability to restore availability and access in a timely manner after an incident. A successful backup job does not establish that the business can restore a usable service.

Set recovery expectations based on the processing and the consequences of interruption. Test restoration, dependencies, credentials, and the handling of personal data in recovered environments. Keep evidence of what was restored, how long it took, what failed, and what was corrected. Retention and erasure rules must also account for backup behaviour.

Test effectiveness with relevant evidence

Article 32 includes a process for regularly testing, assessing, and evaluating measures. The appropriate method depends on the control: access reviews, restoration exercises, configuration checks, vulnerability assessment, supplier review, and incident exercises can all contribute.

A penetration test can be useful, but it is not a universal substitute for these activities or a blanket GDPR requirement. Record the tested scope and limitations. A test of one application does not establish that a newly introduced marketing export, supplier connection, or recovery process is adequately controlled.

For each material safeguard, keep an owner, implementation description, relevant evidence, assessment date, and next review trigger. This is a practical evidence structure, not a prescribed Article 32 template.

Reuse the ISMS without merging security and privacy conclusions

ISO/IEC 27001 concerns a scoped information security management system. Its risk assessment, risk treatment, operational processes, internal audit, and management review can support the management of GDPR safeguards.

The overlap is valuable. Access management evidence, supplier assessments, incident exercises, and recovery tests often need not be recreated for privacy. However, their relevance must be checked against the processing activity and current scope.

Certification by an independent certification body concerns the stated ISMS scope. It does not automatically cover every product, entity, supplier, or processing activity. The Statement of Applicability records control applicability and treatment decisions; it is not a declaration that every GDPR obligation has been met.

ISO 27001 is also not itself a general statutory breach-reporting regime. GDPR notification duties must be assessed separately. Conversely, complying with GDPR does not establish that an organisation has implemented every requirement necessary for ISO 27001 certification.

GDPR does provide for certification mechanisms under Articles 42 and 43. Such certification does not reduce controller or processor responsibility and is not equivalent to an ISO 27001 certificate or a universal declaration of legal compliance.

The management question is therefore evidence reuse with separate conclusions: what does this item demonstrate, for which systems and period, and which privacy questions remain unanswered?

Give management, security, and privacy distinct responsibilities

A workable operating model needs more than a shared compliance inbox. Business owners should describe and justify their processing; security should assess and implement relevant safeguards; privacy specialists should advise on legal requirements, rights, notices, and assessments. Management must provide resources and resolve material decisions within the law.

A DPO is not automatically required for every company. Article 37 includes public authorities and bodies, subject to its judicial exception, and organisations whose core activities meet the specified large-scale monitoring or sensitive-data conditions. National law can add requirements, so check the relevant jurisdictions.

Where appointed, the DPO has independent advisory and monitoring duties, must be involved appropriately and in a timely manner, and reports directly to the highest management level. The DPO should not be instructed to reach a preferred conclusion or assigned conflicting responsibilities that determine processing purposes and means.

Do not make the DPO the owner of every control, the approver of every business purpose, and the person auditing those same decisions. That concentrates incompatible responsibilities and can leave operating teams believing that accountability has been transferred away from them.

A useful approval record identifies the proposing owner, specialist advice, evidence considered, decision-maker, conditions, and unresolved actions. If management chooses a different lawful approach from the one recommended, record the reasoning. Management cannot turn a missing legal basis or mandatory contractual provision into compliance by labelling it “risk accepted.”

The CISO and DPO responsibilities guide explains the ownership boundary in more detail. For the CEO, the key oversight question is whether disagreements reach someone able to change the processing, fund the safeguard, or stop the proposal—not merely approve a document.

Assess suppliers through role, contract, and implementation

Supplier security review and GDPR supplier review overlap, but are not identical. First establish whether the supplier is a processor, an independent controller, a joint controller, or occupies different roles for different services.

Under Article 28, controllers must use processors providing sufficient guarantees for appropriate technical and organisational measures. Processor arrangements require a binding contract or other qualifying legal act covering the prescribed content. A confidentiality clause alone does not meet that requirement.

The Article 28 requirements include:

• Subject matter, duration, nature, and purpose of processing.
• Types of personal data and categories of individuals.
• The controller's obligations and rights.
• Processing on documented instructions, including the relevant transfer provisions.
• Confidentiality and Article 32 security measures.
• Conditions for engaging other processors.
• Assistance with rights requests and specified compliance obligations.
• Return or deletion of data at the end of services, subject to applicable legal requirements.
• Information and audit arrangements to demonstrate compliance.

Review the actual service terms alongside the agreement. A supplier might promise deletion while retaining some logs under a separate controller purpose. An enterprise subscription might restrict training use while a trial account does not. A processor may use several subprocessors with different locations and support arrangements.

Subprocessor authorisation can be specific or general under Article 28. Where general written authorisation is used, the processor must inform the controller of intended additions or replacements, giving an opportunity to object. The operational question is who receives those notices and evaluates them before they disappear into an unattended inbox.

Keep contract review separate from transfer assessment. An Article 28 agreement does not, by itself, provide a Chapter V transfer mechanism. Nor does signing a processing agreement establish the lawful basis for the controller's activity.

Handle non-negotiable terms as a business decision

Smaller customers may have limited negotiating power. That makes early assessment more important, not optional. Document the deficiency, ask for available alternatives, and consider changing configuration, reducing data, choosing another service, or not proceeding.

Where a mandatory requirement remains unmet, executive approval cannot cure it. Where the issue is a choice among lawful options with different residual risks, management can decide with documented advice. Procurement should distinguish those situations rather than collecting every concern under one exception category.

A supplier review should end with a decision, conditions, evidence references, and re-review triggers—not just a completed questionnaire.

Design rights handling before the first difficult request

Articles 15–22 provide rights including access, rectification, erasure, restriction, portability, objection, and protection concerning certain solely automated decisions. These rights have different conditions and exceptions; a single “delete everything” workflow will not serve them all.

Under Article 12, organisations must respond without undue delay and normally within one month of receiving a request. An extension of up to two further months is possible where necessary, considering complexity and the number of requests, but the person must be informed within the first month with reasons. Requests are generally free; fees or refusal are limited to the regulation's conditions, such as manifestly unfounded or excessive requests, which the controller must substantiate.

Build an operational path that works across support, HR, sales, and privacy channels:

1. Record receipt, requested rights, and the deadline.
2. Confirm the relevant controller and scope.
3. Verify identity proportionately where there are reasonable doubts.
4. Locate data and identify relevant systems, recipients, and processors.
5. Assess applicable conditions, exemptions, and other people's rights.
6. Prepare the response or action and review it.
7. Deliver securely and retain an appropriate completion record.

Do not routinely demand identity documents when less intrusive verification would suffice. Equally, do not release sensitive records because someone knows an email address. Verification itself processes personal data and needs a proportionate approach.

An access response normally needs more than a list of categories. Article 15 includes a copy of personal data undergoing processing and supplementary information. Review third-party information and rights before disclosure; do not treat the presence of another person's name as justification for withholding everything.

Erasure is not absolute. Legal retention duties and other Article 17 exceptions may apply. When deletion is required, determine how it reaches connected services and relevant recipients, and how backup restoration avoids casually reintroducing erased records. Explain any lawful limitations accurately.

Automation can track deadlines and organise searches, but someone must decide whether results are complete, whether redactions are justified, and whether an exception applies. A standard response generated quickly is not useful if it omits a system containing the requested data.

See subject access requests for a more detailed workflow. Leadership should periodically test a representative request from intake to secure delivery, rather than relying solely on a procedure being published.

Use DPIAs to challenge the design before approving it

An Article 35 data protection impact assessment is required before processing that is likely to result in a high risk to people's rights and freedoms. The regulation identifies particular cases, including certain significant automated evaluations, large-scale sensitive-data processing, and systematic large-scale monitoring of publicly accessible areas. Relevant supervisory-authority lists must also be considered.

Screen proposed activities early. As a practical recommendation, preserve the reasoning when screening concludes that a DPIA is unnecessary, especially for borderline cases. A short screening record makes it possible to revisit the decision when scale, technology, or purpose changes.

The full DPIA should address four connected elements:

• A systematic description of the envisaged processing and purposes, including legitimate interests where relevant.
• Necessity and proportionality in relation to those purposes.
• Risks to individuals' rights and freedoms.
• Measures envisaged to address risks and demonstrate compliance.

Do not begin and end with a security threat list. First ask whether the proposed data, frequency, recipients, and decision process are necessary. A less intrusive design may remove a risk more effectively than an additional technical control.

For example, an employee productivity project might propose collecting continuous screenshots. Encryption and restricted access could reduce disclosure risk, while leaving serious questions about proportionality, monitoring, employee expectations, and the suitability of less intrusive measures. The business purpose needs examination before the security design can make sense.

Assess risk to people, not only exposure to the company

Consider financial loss, discrimination, identity misuse, loss of confidentiality, exclusion from services, and other relevant effects. A scenario can have limited financial impact on the company and substantial impact on an individual.

Document proposed mitigations, implementation owners, and the residual assessment. Seek DPO advice where a DPO is designated. Review whether changes in the operation or risk require updating the assessment.

Article 36 requires prior consultation with the supervisory authority where the DPIA indicates that processing would result in high risk in the absence of measures taken to mitigate it. If the organisation cannot sufficiently address that high risk, it cannot substitute an internal “accepted” status for the required consultation. Management can redesign, defer, or abandon the activity; it cannot dispose of other people's rights as though they were solely a commercial risk.

Connect incident response to GDPR notification decisions

A personal data breach includes a security breach leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data. It is broader than an attacker stealing a database. A misdirected attachment, lost unprotected device, or incident affecting the availability or integrity of personal data can require assessment.

Under Articles 33 and 34, controllers assess two different notification thresholds:

The 72-hour period runs from awareness, not simply the original incident timestamp or the next working day. If notification is later, reasons for delay must accompany it. Information can be provided in phases where it is not possible to provide everything at once without further undue delay.

Prepare the escalation chain in advance: incident lead, privacy adviser, responsible controller decision-maker, technical investigators, communications, and supplier contacts. Locate the appropriate authority's reporting route before an emergency. A processor should not wait for its own final risk conclusion before informing the controller.

The incident record should capture what happened, the data and people affected, likely consequences, containment and remediation, and notification decisions. Article 33(5) requires documentation of personal data breaches, including their facts, effects, and remedial action. Preserve non-notification reasoning so the decision can be understood later.

Encryption may affect the risk and Article 34 analysis, but only where its protection is relevant and effective. “The service uses encryption” is not enough if an attacker accessed plaintext through a compromised account. Article 34 also includes other exceptions, such as subsequent measures ensuring that the high risk is no longer likely to materialise; assess the actual conditions rather than applying a generic exemption.

Practice one scenario involving a supplier and another involving internal disclosure. The exercise should test evidence collection and decision authority as well as technical containment.

Treat international transfers as a separate assessment

Chapter V transfer requirements sit alongside the rest of GDPR. A transfer mechanism does not supply an Article 6 legal basis, and a legal basis does not remove the need for an appropriate transfer arrangement.

Map actual recipients and access paths. Hosting in an EU data centre is relevant, but does not by itself establish that no third-country transfer occurs or that all privacy obligations are satisfied. Consider support access, subprocessors, administrative access, onward disclosure, and the parties involved.

The GDPR transfer framework includes adequacy decisions under Article 45, appropriate safeguards under Article 46, and limited derogations under Article 49. Check the relevant mechanism and its scope at the time of the decision.

Where relying on an adequacy arrangement limited to participating organisations, verify the exact recipient and covered activity. A group company or similar trading name is not necessarily the covered recipient. Preserve the result and date of the check.

Where standard contractual clauses are used, select clauses matching the parties' actual roles and complete the relevant annexes. Assess destination-country laws and practices and whether supplementary measures are needed to make the protection effective. A signed contract alone does not answer every transfer-risk question.

A practical transfer file should identify the exporter and importer, data and purposes, locations and access, onward transfers, selected mechanism, relevant assessment, technical or organisational measures, and review triggers. Provider documentation can support this work, but asking whether a provider “has an assessment” is not the same as evaluating its relevant findings.

Management should know which services depend on a particular mechanism and what changes would require re-evaluation. That supports a deliberate contingency plan without implying that every supplier needs an identical contractual fallback.

Assess AI use as processing, not merely as a new tool

An AI application can introduce new recipients, infer additional personal information, retain prompts, or enable a new purpose. Those changes matter even if the application reuses the organisation's existing sign-on and access controls.

Before approving personal data in an AI service, establish:

• The precise task and whether personal data is necessary.
• The categories of input, output, and affected individuals.
• The provider's role for each use, including any training or improvement purposes.
• Retention, human access, subprocessors, and transfer arrangements.
• Contractual commitments and relevant configuration settings.
• Accuracy, disclosure, rights-handling, and decision-making risks.

Do not assume that every model provider is exclusively a processor. Its role depends on the processing it performs and the purposes it determines. Likewise, an Article 28 agreement does not automatically make the proposed transmission lawful. Assess purpose, legal basis, transparency, necessity, and all other applicable requirements.

If the company is itself a processor, introducing an AI provider may create a subprocessor relationship. Check customer instructions and the agreed authorisation process before sending customer data. A new contract amendment is not invariably required, but compliance with the existing contractual and statutory arrangements is.

Article 22 addresses certain decisions based solely on automated processing that produce legal or similarly significant effects. A nominal human review does not resolve the issue if the reviewer cannot meaningfully assess or change the outcome. Recruitment, eligibility, and financial decisions need particular scrutiny.

The AI Act and GDPR impose distinct obligations. An AI Act assessment does not discharge a DPIA, and GDPR compliance does not establish AI Act compliance. Use the European Commission's current AI Act overview for applicability dates rather than carrying an old launch timetable into a current project.

For internal privacy work, AI can draft descriptions from approved sources, compare documents, or suggest questions. Treat its output as a draft. A plausible legal basis, missed recipient, or incorrect retention statement can make a polished document materially wrong.

Automate coordination while preserving accountable review

Growing organisations accumulate recurring work: processing-record updates, rights-request deadlines, supplier documents, assessment actions, evidence expiry, and review decisions. Automation can organise inputs and deadlines. It should not obscure the difference between collecting information and reaching a defensible conclusion.

Start with a stable process and clear ownership. Automating an ambiguous handoff can distribute the ambiguity faster. Define what opens a task, who receives it, what evidence is needed, who reviews the result, and what completes the work.

For AI-assisted drafting, preserve the approved sources and identify uncertainty. Do not let a generated summary silently replace a supplier contract or an assessment. Reviewers should be able to distinguish supplied facts, inferred suggestions, and unresolved questions.

Apply least-privilege access to the workflow itself. Rights-request files, incident records, and employee assessments can contain sensitive information. Broad access to a compliance workspace may undermine the restrictions being documented. Minimise personal data in evidence and restrict material that genuinely requires identification.

Useful management measures include overdue actions, missing owners, records awaiting review after a material change, and controls with stale or insufficient evidence. Raw document counts are less informative. Measure whether decisions and corrective work are completed, not merely whether more text has been generated.

Worked example: a marketing integration that reuses security controls

The following example is illustrative. Assume a growing B2B software company has an established customer database, an ISMS covering its production service, and a proposed campaign platform. Marketing wants to send onboarding messages and later promote additional products. The platform would receive contact details, product-use events, and free-text support notes. No real customer outcome or Secani capability is implied.

1. Separate the proposed purposes

The initial request says “improve customer engagement.” The business owner rewrites it into specific purposes: necessary service onboarding, optional promotional communications, and campaign performance analysis.

The privacy reviewer assesses the basis for each purpose rather than applying the customer contract to all three. Promotional communications may also engage applicable national electronic-marketing rules. The company does not assume that a GDPR legitimate-interests analysis alone resolves those separate requirements.

The first deliverable is a purpose-and-basis decision with unresolved questions assigned. Marketing cannot begin the expanded use merely because the integration has passed a technical security check.

2. Reduce the proposed data flow

Support notes are convenient for personalisation, but unnecessary for the approved onboarding message. They may also contain information customers did not expect to be repurposed for marketing. The design removes them.

The technical owner limits product events to those needed for the approved workflow and excludes detailed user histories where aggregate or simpler event data will suffice. This reduces exposure before adding another control.

The processing record now describes the actual fields, affected users, recipient, purposes, and retention approach. The privacy notice is reviewed against the approved activity rather than the original broad request.

3. Check supplier and transfer arrangements

Procurement establishes the platform's role for campaign delivery and checks for separate provider purposes. The team reviews the Article 28 agreement, subprocessor arrangements, deletion terms, support access, and the applicable transfer mechanism.

An EU hosting option is recorded as a relevant fact, not treated as the end of the transfer analysis. If required information is missing, the task remains open and the launch condition identifies what must be resolved.

4. Reuse security evidence carefully

The integration can reuse corporate identity controls and an existing access-management process. Evidence of those controls is linked rather than recreated. However, the new campaign platform has its own permissions, exports, and retention settings.

The security owner assesses account compromise, unauthorised bulk export, incorrect event mapping, and loss of suppression preferences. The team limits access, approves the required integration permissions, tests the mapping with suitable test data, and checks how records are deleted or suppressed.

The existing production-service recovery exercise does not prove that campaign preferences can be restored correctly. The owner separately checks recovery behaviour relevant to this workflow.

5. Complete assessment and approval

The privacy reviewer screens for a DPIA based on the actual activity and records the reasoning. The team also verifies how access, objection, and erasure requests reach the platform. In particular, a marketing objection must not be undone by the next database synchronisation.

Management reviews a concise decision package: approved purposes, data removed, supplier and transfer conclusions, safeguards, open conditions, rights handling, and named owners. Any unresolved mandatory requirement blocks the affected processing rather than being converted into an accepted commercial exception.

6. Preserve the next trigger

The approval is tied to the assessed configuration. Adding behavioural scoring, uploading support notes, changing provider training terms, or introducing a new recipient triggers review. The team can reuse unchanged security evidence while reassessing the new privacy questions.

This is the central distinction: common safeguards can remain valid while the purpose, recipient, or effect on people changes materially.

Put the approach into operation with a focused first scope

Choose one processing activity with visible business ownership and manageable dependencies. Customer support, employee onboarding, or a representative product workflow can reveal gaps without requiring an organisation-wide redesign first.

As a practical recommendation, begin with four deliverables:

• An agreed processing description and role assessment.
• A list of privacy decisions, including basis, notice, retention, rights, and DPIA screening.
• A scenario-based safeguard assessment linked to existing security evidence.
• An approval record with owners, open actions, and change triggers.

In Secani, teams can start with a focused scope, model supporting applications, systems, services, and providers, and connect evidence to requirements, controls, and decisions. Missing evidence and unresolved review questions can become assigned tasks. AI-assisted suggestions remain draft work, with source traceability and explicit human approval. This gives security and privacy reviewers a shared evidence context while keeping their distinct conclusions visible; it does not replace processing records, rights fulfilment, or legal analysis.

Expand only after the first workflow has been exercised. Test a supplier change, a rights request, and a relevant incident scenario against it. Where the team cannot identify the owner, retrieve evidence, or explain the decision, correct the operating process before adding more activities.

For management review, ask three questions: does the record match current processing, do safeguards address consequences for people, and will a material change reliably reopen the decision? Those questions provide a practical next step for connecting security assurance to GDPR accountability.

Questions leadership should settle explicitly

Can a CEO approve a GDPR exception?

Management can choose among lawful options and allocate resources to address risk. It cannot waive statutory requirements, authorise processing without an applicable basis, or replace required prior consultation with internal approval.

Does every processing change need a new DPIA?

No. Assess the change against the high-risk threshold and review existing assessments where the operation or risk changes. A documented screening decision is more useful than either automatically producing a full DPIA or assuming the old result always applies.

What should be reviewed first when resources are limited?

Prioritise processing with potentially serious consequences for people, unresolved legality or contractual questions, and operational deadlines such as rights requests and breach response. Use evidence gaps to guide investigation, but do not assume that the activity with the most missing documents necessarily presents the greatest risk.

Which authority enforces GDPR, and what can breaches cost?

Identify the competent supervisory authority for the processing. For qualifying cross-border processing, the lead-authority mechanism generally depends on the controller's or processor's main or single EU establishment, with other concerned authorities involved. An Article 27 representative does not create an EU establishment or access to that mechanism.

Article 83 provides two principal maximum administrative-fine tiers: up to €10 million or 2% of an undertaking's total worldwide annual turnover for the preceding financial year, and up to €20 million or 4%, whichever is higher in each tier. The applicable tier depends on the infringement; these are ceilings, not automatic penalties. Authorities consider the circumstances and can also order corrective action or restrict processing. Article 82 separately provides for compensation where an infringement causes material or non-material damage.