GDPR Compliance Consulting for Software Companies

Yes, Article 3(2) gives GDPR extraterritorial reach. If you offer goods or services to data subjects in the Union (paid or free), or you monitor their behaviour (analytics, profiling, retargeting), you are in scope regardless of where your servers or HQ sit. You will need an Article 27 EU representative unless you fall under the narrow exemption. Penalties under Article 83(5) reach 20 million euros or 4 percent of global annual turnover, whichever is higher. We deliver the Article 27 representative appointment, the Article 30 records, the Article 28 processor contracts, and the Article 32 security baseline as one integrated package rather than five separate workstreams.

Article 30 RoPA (Records of Processing Activities) is mandatory for almost every controller and processor — a living inventory of every processing purpose, lawful basis under Article 6, categories of data subjects and data, retention, recipients, and transfers. Article 35 DPIA is required when processing is likely to result in high risk to rights and freedoms — large-scale special-category processing, systematic monitoring, automated decisions with legal effect, new technology. A TIA (Transfer Impact Assessment) is required under Schrems II whenever you rely on Article 46 SCCs for transfers to a third country without an adequacy decision. We deliver all three using a single source-of-truth data map so they stay synchronised instead of drifting.

Three lawful routes under Chapter V (Articles 44–49). First, Article 45 adequacy — the EU-US Data Privacy Framework is currently valid; certify under it and you can transfer to certified US importers without further measures. Second, Article 46 Standard Contractual Clauses (the 2021 EU SCCs, four modules) combined with a Transfer Impact Assessment and supplementary measures per EDPB Recommendations 01/2020 — encryption in transit and at rest under your sole key control, split processing, contractual transparency obligations. Third, Article 49 derogations for specific situations — narrow, never a default. We draft the SCC package, the TIA, the supplementary technical measures, and the customer-facing transparency notice as one bundle.

Article 32(1) requires technical and organisational measures appropriate to the risk, including (a) pseudonymisation and encryption, (b) ongoing confidentiality, integrity, availability and resilience, (c) the ability to restore availability and access after an incident, (d) a process for regular testing, assessing and evaluating effectiveness. In practice for SaaS that means encryption in transit (TLS 1.2+ minimum, ideally 1.3), encryption at rest (AES-256, KMS-managed keys), MFA for admin access, RBAC with least privilege, audit logging with tamper resistance, vulnerability management with documented SLAs, annual penetration testing, an incident response runbook tied to the Article 33 72-hour breach notification clock, and a BCP/DRP with measured RTO/RPO. We implement and document each of these to evidence Article 32 compliance under audit.

They overlap on controls but differ on framing. ISO 27001 Annex A controls (especially A.5, A.8, A.18) map almost 1:1 to GDPR Article 32. SOC 2 Trust Services Criteria CC6 (logical access), CC7 (system operations) and the optional Privacy category P1–P8 cover most Article 25 and 32 ground. The EU AI Act Article 10 data governance for high-risk systems borrows directly from GDPR Articles 5, 25 and 35. We build one unified evidence library that discharges all four regimes — same encryption control evidences SOC 2 CC6.7, ISO A.8.24, GDPR Article 32(1)(a), and AI Act Article 15. You do the work once; the auditors get what each of them needs.

Three engagements. GDPR Readiness Assessment is a fixed-scope two-week phase with the budget agreed before work starts: scope confirmation, Article 30 RoPA in your data-mapping tool, gap analysis against Articles 5, 6, 12–22, 25, 28, 30, 32, 33–34, 35 and 44–49, remediation roadmap, executive briefing. Implementation Pack is a fixed-scope six-to-eight-week phase, budget agreed up front: DPA template for processors and sub-processors, Article 35 DPIA template plus one worked DPIA, Article 32 technical measures implementation, Articles 12–22 data-subject rights workflows in your product, SCC and TIA pack for EU-to-third-country transfers, breach response runbook, public privacy notice. Ongoing DPO-as-a-Service is a monthly retainer with transparent scope: quarterly evidence refresh, regulator monitoring (EDPB, ICO, CNIL, BfDI, AEPD, Garante guidance), DSAR triage support, breach support, vendor DPA reviews up to 10/month, annual audit dry run. Budgets are agreed in writing before any work begins — fixed scope per phase, no enterprise markup.

Article 37 mandates a DPO for: (a) public authorities and bodies; (b) controllers or processors whose core activities involve large-scale, regular and systematic monitoring of data subjects; (c) controllers or processors whose core activities involve large-scale processing of special-category (Article 9) or criminal-offence (Article 10) data. “Large-scale” has no hard number — the EDPB looks at data subjects affected, volume, duration, and geographic extent. Most SaaS companies under approximately 100k EU users do not hit the threshold, but a voluntary DPO or the functional equivalent under a DPO-as-a-Service retainer is defensible and reduces Article 83(4) risk. We assess the threshold for your specific processing profile rather than applying a blanket rule.

Article 7 consent must be freely given, specific, informed and unambiguous — an opt-in, not an opt-out. Consent is the right basis only when the data subject has a genuine, granular choice with no imbalance of power. Employment relationships and most B2B software use cases should use Article 6(1)(b) (contract) or 6(1)(f) (legitimate interest), not consent — because if withdrawal stops the service, the choice was never free. Marketing profiling and non-essential cookies remain the canonical consent use cases. Over-relying on consent creates operational fragility: every withdrawal triggers deletion or suppression obligations across every system that holds the data.

Yes. Business email addresses (firstname.lastname@company.com), work phone numbers and job titles are personal data under Article 4(1) regardless of the B2B context. Article 6(1)(f) legitimate interest is typically the right basis for B2B prospecting and account-based marketing, provided the balancing test is satisfied. We document the legitimate interest assessment (LIA), wire the Article 21 opt-out mechanism, and build the suppression list that ensures opt-outs are honoured across your CRM and marketing stack — not just one system.

Article 12 gives a one-month response window, extendable by two months for complex requests. The four-step pipeline: receive and validate identity (Article 12(6) allows proportionate checks), locate data across every system in the Article 30 RoPA, compile and redact (remove third-party data that would disclose others’ information), respond. The failure modes are missing the deadline, disclosing too much, and disclosing too little — all open supervisory authority complaints. We build the DSAR pipeline in your product, define SLAs per request type, and establish the third-party redaction policy before the first request arrives.

Article 28(2) requires written controller authorisation before a processor engages a sub-processor — either specific prior approval (named list) or general written authorisation with an objection window for new additions. Article 28(4) requires processor-to-sub-processor contracts with identical Article 28(3) obligations. The processor remains fully liable to the controller if the sub-processor fails. In practice: maintain a current sub-processor list (Stripe, AWS, SendGrid, Intercom and others), update the customer-facing notice at every change, give customers the objection window, and keep a matrix mapping which sub-processor touches which data category. We build this as a repeatable ops workflow, not a one-time document.