We are planning an EU launch for a platform that uses shared infrastructure and has its primary database in Australia. GDPR looks like it will involve application changes as well as infrastructure and documentation.
How would you approach data transfers, deletion and backups, logging, third-party services, and access through a global admin portal? Is separate EU infrastructure necessary, and are compliance tools worth considering?
Start by mapping where personal data goes, not by creating a new cloud account. Include the database, backups, logs, support tools, analytics providers and the people who can access each system. Then work out why each use is needed and how long the data is kept.
An Australian database is not automatically forbidden, and GDPR does not generally require all EU data to stay in the EU. Transfers outside the EU still need a lawful basis for processing and an appropriate transfer mechanism or other applicable condition. Get legal advice on the specific flows, including remote access by staff and providers.
Separate EU infrastructure might make some controls easier, but it is an architecture choice, not a blanket GDPR requirement. Map the flows first so you know what separation would actually solve.
Deletion and backups deserve an early design discussion. A practical pattern is to record deletion requests and reapply them after restoring an older backup, before restored data is put back into use. You still need retention limits, access controls and a documented process for handling the data while it remains in backups.
Per-user encryption keys are another possible design. Destroying a key can make associated data inaccessible without rewriting every snapshot, but it only helps if copies of that data and the keys are actually accounted for across the system. It is not a magic delete button.
Erasure is not absolute. Some records may need to be retained for legal reasons, so distinguish those from data you can remove. GDPR generally requires a response to a request within one month, with limited extensions in some cases. Work out the backup treatment with your legal advisers rather than assuming every snapshot must be edited immediately.
Check your logs before they become a much bigger cleanup. Request bodies, email addresses, IP addresses and support diagnostics can end up in places nobody thought of as a customer database.
I'd first stop collecting fields that aren't needed, then add redaction where useful and set retention periods. Review existing logs separately. Hashing identifiers can reduce exposure, but hashed data can still be personal data, so don't treat it as automatic anonymization.
A global admin portal can work, but give it deliberate boundaries. Restrict access by role and customer or region where appropriate, keep an audit trail, and have a process for granting and removing exceptional access.
Also check what the portal actually exposes. A role that only needs to troubleshoot an account may not need full access to customer records. Regional restrictions can reduce exposure, but they don't replace an assessment of cross-border access or vendor arrangements.
Compliance tools may help organize evidence and track controls, but they won't decide your data flows or make the application compliant for you. I'd compare them after mapping the work, when you can tell whether you need help with evidence collection, access reviews or another specific task.
Don't leave vendors until the end either. Inventory which services receive personal data, what they do with it, where they process it and what contractual arrangements are in place. A service that looked incidental during development may be part of your transfer and deletion planning.
Answers are reviewed before publication.
4x!postbox_638:
Does access from a global admin portal need to be considered even if the database itself stays in the EU?
_b93~folderclasp:
Yes. Look at where the people and services accessing the data are located, not just where the database sits. Have counsel assess the access arrangements and transfer implications.