Self-hosted SailPoint alternative for EU data sovereignty

A records of processing register under Article 30 of the GDPR is usually the first document requested, and the midPoint deployment should appear in it as its own processing activity. Record the purposes, the categories of identities and attributes, the recipients, the retention periods and a general description of security measures. Add the hosting location and any third-country access path, because those fields feed every later question about transfers. Keep the register dated and versioned, and update it when you add a connector, change a retention rule or move a database server. Your data protection officer owns the register, so the engagement covers preparing the technical facts for the midPoint entry, not signing off on it. Confirm the exact field list with counsel and your supervisory authority guidance before the audit. The GDPR text on EUR-Lex is the starting point.

A transfer impact assessment is the documented check that a transfer tool, such as standard contractual clauses, still protects personal data once the law of the destination country is considered. The controller or exporter is responsible for it, and it must address whether public authorities in the destination could reach data beyond what is necessary and proportionate. For a self-hosted midPoint in an EU datacenter with no third-country support access, the assessment can be short, but it still needs to be written and dated. The EDPB recommendations on supplementary measures explain the steps and the cases where no technical measure is effective. Legal counsel should own the conclusions. DeployOpen can document the technical facts of the design, such as where keys are held, who has remote access and which providers touch the data.

A data location map lists every place identity data is stored or processed, with its country, operator and access path. The map has to cover more than the primary database, because auditors will expect each of these locations to be named:

• The midPoint application nodes and the load balancer
• The PostgreSQL repository, its replicas and any reporting copy
• Backups, snapshots and offline copies
• Logs and monitoring stores that may contain identity attributes
• Remote access paths, including vendor support sessions, since EDPB Guidelines 05/2021 treat remote access from a third country, even only displaying data, as a transfer

Mark which locations sit inside the EEA and which do not, and state who can reach each one. Refresh the map after every infrastructure change, and date each version so the history can be shown.

Collect a signed data processing agreement with every provider in the chain, plus a current sub-processor list and the location of each sub-processor. If any party in the chain is outside the EEA, the transfer needs a valid mechanism, usually the standard contractual clauses in Commission Implementing Decision (EU) 2021/914, backed by a transfer impact assessment. A self-hosted midPoint has a shorter chain: your hosting provider or datacenter operator, your network and backup vendors, and Evolveum only if you buy a subscription or training. Compare this with the vendor lists you already hold. SailPoint's sub-processor page names affiliates and US-based sub-processors for support and product operations, which shows the kind of list an auditor will expect from any cloud provider. Ask each provider to confirm data location and remote access in writing, and keep the dated copies together.

Auditors want evidence that every privileged action on identity data traces to a named person, and that the log trail cannot be quietly edited. In midPoint, confirm which audit events the platform records, where they are stored and how long they are kept, using the audit configuration in your deployment. Administrative access is also logged at other layers: the operating system, the hypervisor or container platform, the PostgreSQL server, the load balancer and the backup system. Forward these logs to a store that the identity platform administrators cannot edit, then test the chain by performing a known action and finding it in the trail. Document who holds administrator roles and review that list on a set schedule. DeployOpen can configure and test this logging as part of an implementation, while your policy sets the retention period.

Keep a backup location record that names each backup target, its country, its operator, its encryption method and who holds the keys. Include the PostgreSQL dumps or base backups, the exported midPoint configuration and any offsite or cloud copies, since each one contains personal data within scope. Auditors will also ask for restore evidence: dated records of test restores showing that the identity repository can be recovered within the recovery target your organization has set. Confirm that backup retention and deletion follow the same rules as the primary data, because data that should be erased can survive in old backups. Store encryption keys apart from the backups they protect. DeployOpen can design and document the backup and restore procedure and record the test results, while your policy defines the retention periods and recovery targets.

Export the configuration that defines your controls, keep it under version control and record every change with its reason and approver. For access certifications, keep the campaign definitions, reviewer assignments, stage settings, remediation actions and dated results from each review cycle. Keep the role and policy rules that drive provisioning, because an auditor will test whether a joiner, mover or leaver event produces the access you describe. Record the test evidence from a non-production environment and link it to the change that introduced each rule. Confirm with Evolveum's documentation how each certification and audit object is exported and what reports your midPoint version can produce. DeployOpen can prepare the configuration, test scripts and evidence folder, while the independent auditor decides whether the controls are adequate.

No. DeployOpen prepares systems, controls and evidence for a compliance assessment, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies issue those, and you engage them directly. In practice, DeployOpen documents the design, configures and hardens midPoint, collects the technical evidence described above, and sets up the logging and backups that produce it. Your team owns the policies, the risk decisions and the records of processing, and the auditor tests the result. Engagements are usually fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask any auditor you are considering which evidence formats they accept, since some want exports, some want screenshots and some want both.