Vendor privacy risk software that knows what every processor does with your data

It should show the processor role, data access, DPA status, sub-processors, review date, transfer safeguards and connection to the Article 30 RoPA. Acompli keeps those facts as connected Knowledge Base records rather than a static vendor spreadsheet.

Track the DPA, due-diligence evidence, sub-processor authorisation, transfer mechanism, TIA where required, open risks and review decisions. Acompli links those items to the supplier record so an audit export is a current record, not a reconstruction.

Acompli runs a structured Vendor Privacy Assessment, tracks DPA status against Article 28 requirements, and flows approved outputs to the risk register and Article 30 RoPA with evidence links back to the source response.

For suppliers outside the EEA, the register should capture the transfer mechanism (Standard Contractual Clauses, an adequacy decision, or a derogation), the Transfer Impact Assessment and its supplementary measures, the supplier's location, and any sub-processor chain that leaves the EEA. This operationalises the CJEU's Schrems II ruling (Case C-311/18) and the EDPB's supplementary-measures recommendations — and it matters in Ireland in particular, where the DPC is the lead supervisory authority for many large US-headquartered processors. Acompli links each transfer to its safeguards and TIA so the position is evidenced, not asserted.

The Vendor Privacy Assessment is a structured due-diligence framework in the template library — covering security posture and certifications, sub-processor arrangements, incident notification and breach procedures, data deletion and return, transfer mechanisms and safeguards, and contractual compliance status. Questions that reference processors and IT systems use Knowledge-Base-linked types, so respondents select from your actual inventory rather than entering free text. When the assessment is complete, extracted risks flow to the Risk Register with evidence links back to the source responses, and the processor record is updated with the outcome and review date.

When RoPA entries are generated from approved DPIAs, Acompli synthesises the Article 30 processing record from the assessment responses and the Knowledge Base entities selected during the assessment — processor names and DPO contacts from Third Party records, systems and data residency from IT System records, storage locations from Location records, and transfer safeguards and contract details from each entity's registered fields. The RoPA is derived from assessed, approved relationships rather than maintained as a separate document, so when a processor relationship changes the next assessment produces an updated entry reflecting the current position.

Yes. Bulk import accepts Excel and CSV and uses AI column mapping to interpret your existing headers and data values against the Knowledge Base schema, with confidence scores per column and per-field lineage; low-confidence mappings are flagged for review before anything is committed. A mixed file of IT systems, vendors and locations is detected and separated into the correct registers, and you can import directly from SharePoint, Google Drive or OneDrive, or use a pre-formatted template.

Yes. A Knowledge Base assistant lets you ask in plain English — for example “which vendors process health data?”, “what systems are missing ISO 27001?”, or “which third parties are outside the EU?” — and get answers with sources drawn from your actual inventory, with no spreadsheets to export or reports to build.

When a Vendor Privacy Assessment is approved in Acompli, the processor's registered fields — DPO contact, sub-processor list, transfer mechanism, Data Processing Agreement reference, and any Transfer Impact Assessment outcome — become the source of truth for that processor across the platform. When you generate a RoPA entry from an approved DPIA, the Article 30(1)(d) recipients block, the Article 30(1)(e) third-country transfers block, and the Article 30(1)(g) security-measures block are synthesised from those assessed values rather than being typed in. This means the Article 30 register reflects what the assessment actually evidenced — the kind of demonstrable accountability under Article 5(2) that the DPC and ICO expect when they audit processor oversight.

In an Irish supervisory audit, the DPC typically asks to see a current processor inventory, the Article 28 written contract for each processor, the due diligence completed before engagement, the sub-processor list with the controller's prior written authorisation under Article 28(2), the transfer mechanism and any Transfer Impact Assessment for non-EEA suppliers, and how breaches by a processor would be notified to you within 72 hours under Article 33. Records must be evidenced, current and reconcilable to the Article 30 RoPA — Article 5(2) accountability means asserting these controls is not enough. Acompli holds each of these as connected Knowledge Base entities, so the audit pack is a query, not a reconstruction project.

Under Article 28(2) of the GDPR, a processor may not engage a sub-processor without the controller's prior specific or general written authorisation; where the authorisation is general, the processor must inform the controller of any intended addition or replacement of sub-processors and give the controller the opportunity to object. Under Article 28(4), the same data-protection obligations set out in the controller-processor contract must be imposed on the sub-processor by a contract or other legal act, and the initial processor remains fully liable to the controller if the sub-processor fails to meet them. Acompli keeps the sub-processor list, its authorisation status and the onward-transfer context on each vendor record, so the prior-authorisation trail and any objection are evidenced rather than reconstructed, and non-EEA sub-processors are flagged for transfer review.

Under the EU AI Act (Regulation (EU) 2024/1689), obligations run along the AI value chain. Providers of high-risk AI systems must supply deployers with clear instructions for use and the information needed to use the system appropriately (Article 13), and deployers have their own duties, including using the system in line with those instructions and ensuring human oversight (Article 26). A system is high-risk under Article 6 either as a safety component of a regulated product (Annex I) or because it falls within an Annex III use case, subject to the Article 6(3) exception. Certain systems also carry Article 50 transparency obligations, and providers of general-purpose AI models have separate obligations (Article 53). For a privacy team, AI suppliers are third parties: Acompli records which vendors provide AI, captures the provider's documentation and the system's role, and flags them for EU AI Act review. Whether a system is high-risk is a legal classification a person assesses and records on the EU AI Act workflow, not something the tool decides on its own.

The best third-party risk management software is decided less by how many questionnaires it sends than by whether each vendor is a governed record that stays current - the Article 28(3) DPA, due-diligence evidence, sub-processor authorisation and transfer safeguards held against the supplier, versioned, and reconcilable to the Article 30 RoPA. Acompli's angle is to govern these as connected, human-approved records tied to the wider GDPR and EU AI Act programme, each vendor decision traceable to approved evidence. For a balanced, unbiased comparison of the available suppliers - evidence-based, drawn from public sources, and honest about where competitors are stronger than Acompli - we have compiled capability charts and vendor-by-vendor breakdowns for you to consider in our full comparison library.