Software development teams working with European customers may encounter personal data in production databases, application logs, test environments, analytics platforms, support tickets, and monitoring tools.
When an Indian development team processes this information on behalf of a controller, GDPR Article 28 can become relevant to the engagement.
For engineering leaders, the challenge is translating contractual privacy requirements into practical engineering and operational controls.
- Establish the Processing Context
Before designing controls, identify what personal data the team can access and why that access is necessary.
A team maintaining a customer-facing application may encounter:
-Names and contact details in customer records.
-Account identifiers and transaction histories.
-IP addresses and identifiable application logs.
-Employee information in administrative systems.
-Personal data copied into support tickets or debugging tools.
Not every technical identifier is necessarily personal data in every context. The assessment depends on whether the information relates to an identified or identifiable individual.
The team should also confirm whether it acts as a processor for the relevant activity and whether GDPR applies to that processing arrangement.
- Implement Documented Instructions
Article 28(3)(a) requires processors to process personal data only on documented instructions, subject to the applicable legal exceptions.
In software delivery, documented instructions can be reflected in approved work items, technical specifications, change requests, access approvals, and service procedures.
Development teams should avoid copying production records into local environments without authorisation. Where possible, use synthetic data or appropriately anonymised datasets for development and testing.
A change that introduces a new data use or third-party service should trigger a review of the authorised processing scope.
- Apply Security Controls Appropriate to Risk
Article 28(3)(c) links processor obligations to the security requirements of Article 32.
Useful engineering controls may include:
-Multi-factor authentication for privileged accounts.
-Least-privilege access to production systems.
-Encryption in transit and at rest where appropriate.
-Centralised logging and security monitoring.
-Secure secrets management.
-Dependency and vulnerability scanning.
-Peer review and controlled deployment procedures.
-Tested backups and recovery plans.
-Periodic access reviews.
These controls should be proportionate to the data, system exposure, and potential impact of a security incident.
- Build Breach Notification Into Incident Response
Article 33(2) requires a processor to notify its controller without undue delay after becoming aware of a personal data breach.
An engineering incident workflow should identify how a suspected incident is escalated, who determines whether personal data may be affected, what evidence is preserved, and who communicates with the controller.
A contractual notification deadline can support operational planning, but it should not be treated as permission to delay notification when the legal requirement applies.
The controller's separate 72-hour supervisory authority notification rule under Article 33(1) should not be confused with the processor's obligation.
- Control Third-Party Integrations
Monitoring agents, error-reporting tools, cloud services, and outsourced support platforms may transmit or expose personal data.
Before introducing a new integration, teams should determine what information it collects, where the information is processed, who can access it, and whether the provider is a sub-processor.
Article 28 requires the relevant prior written authorisation and contractual safeguards for sub-processors. International transfers must also be assessed separately under Chapter V where applicable.
- Manage Data Across Its Lifecycle
The DPA should specify what happens when the engagement ends. Engineering teams may need procedures for removing access, returning data, deleting customer records, handling exports, and addressing backup retention.
Data deletion should be verifiable to the extent appropriate to the system and contractual requirements. Legal retention requirements must be handled separately from routine business convenience.
- Maintain Compliance Evidence
Evidence can include access review records, deployment logs, incident reports, approved supplier lists, processing inventories, and relevant security assessment reports.
ISO/IEC 27001 and ISO/IEC 27701 may help structure information security and privacy management, depending on the scope of implementation and assessment. Neither standard automatically establishes compliance with every GDPR provision.
Engineering takeaway: Article 28 compliance works best when privacy requirements are incorporated into software development, identity management, supplier onboarding, incident response, and data lifecycle automation instead of being treated as a separate paperwork exercise.
Top comments (0)