DORA Third-Party ICT Risk: What Database Teams Need to Know

Why Database Teams Should Care About Article 28

DORA Article 28 requires financial entities to identify, assess, and manage all ICT third-party service providers. For database teams, this includes:

• Managed database providers: AWS RDS, Azure Database, Google Cloud SQL, Supabase, Neon
• Infrastructure providers: Hetzner, OVH, DigitalOcean (if hosting your own PostgreSQL)
• Extension dependencies: Any compiled PostgreSQL extension from a third party
• Compliance tools: SaaS platforms that connect to your database

How pgcomply Minimizes Third-Party Risk

pgcomply is designed to minimize the third-party footprint:

Community Edition: Pure PL/pgSQL file. No external connections, no phone-home, no compiled extensions. It runs entirely inside your PostgreSQL instance. The only dependency is pgcrypto (bundled with PostgreSQL).

Pro Edition: The dashboard connects to your database via a read-only connection string you provide. Your data stays in your infrastructure. The dashboard runs on pgcomply.com but never stores your production data.

Documenting Database Dependencies

-- What extensions are installed?
SELECT name, default_version, installed_version
FROM pg_available_extensions
WHERE installed_version IS NOT NULL;

-- What external connections exist?
SELECT * FROM pgcomply.connection_audit();

-- pgcomply itself: verify no external dependencies
SELECT pgcomply.health_check();
-- All checks run locally, no external calls

Exit Strategy

DORA requires exit strategies for critical ICT providers. For databases:

1. Data portability: pgcomply.export_user_data() exports all user data as JSON. pg_dump exports the full database.
2. Tool independence: pgcomply Community is Apache 2.0 — you own the code, forever. If you stop paying for Pro, Community continues working.
3. Provider migration: pgcomply is pure PL/pgSQL — it works on any PostgreSQL 14+ provider. Switch from AWS RDS to Hetzner without changing a single function call.

Documenting Your ICT Third-Party Register

DORA Article 28(3) requires a register of all ICT third-party arrangements. For database infrastructure:

-- Document your database provider dependencies
-- (Store in a table or use pgcomply tags)

SELECT pgcomply.tag('_infrastructure', 'db_provider', 'Hetzner Cloud');
SELECT pgcomply.tag('_infrastructure', 'db_hosting', 'Germany, FSN1-DC14');
SELECT pgcomply.tag('_infrastructure', 'backup_provider', 'Hetzner Backup');
SELECT pgcomply.tag('_infrastructure', 'monitoring', 'Self-hosted Grafana');
SELECT pgcomply.tag('_infrastructure', 'compliance_tool', 'pgcomply Community (Apache 2.0, self-hosted)');

-- View your third-party register
SELECT * FROM pgcomply.get_tags('_infrastructure');

Provider Comparison: Third-Party Risk Profile

| Provider | DORA Classification | Concentration Risk | Exit Difficulty | |----------|--------------------|--------------------|-----------------| | AWS RDS | Critical ICT TPP | High (if all on AWS) | Medium (pg_dump works) | | Hetzner dedicated | Infrastructure | Low | Low (full control) | | Supabase | Critical ICT TPP | Medium | Medium (pg_dump, but auth is coupled) | | Neon | Critical ICT TPP | Medium | Low (standard PostgreSQL) | | Self-hosted | None (internal) | None | N/A |

Concentration Risk Assessment

If all your databases run on one provider, you have concentration risk:

-- Check: all database connections from health_check
SELECT * FROM pgcomply.connection_audit();

-- If this shows a single cloud provider's IP ranges,
-- document the concentration and your mitigation plan

Mitigation strategies:

1. Multi-provider: Primary on AWS, read replica on Hetzner
2. Backup independence: Store backups on a different provider than the primary database
3. Exit plan: Documented and tested procedure to migrate to a different provider within 30 days

pgcomply's Zero-Dependency Architecture

pgcomply was designed specifically to minimize third-party risk:

External dependencies: 0
Cloud connections: 0
Required extensions: pgcrypto (bundled with PostgreSQL)
Installation: 1 SQL file
Removal: DROP SCHEMA pgcomply CASCADE;

Compare this to a typical SaaS compliance tool:

External dependencies: Cloud API, agent on your server, webhook endpoints
Cloud connections: Your DB → their cloud (metadata + potentially data)
Required services: Their SaaS platform (vendor lock-in)
Removal: Decommission agent, revoke API keys, lose all historical data

For DORA-regulated entities, every external dependency is a risk to assess, document, and monitor. pgcomply eliminates that burden for the compliance tooling layer.

Summary

DORA third-party risk management starts with knowing your dependencies. For database teams, this means documenting your hosting provider, managed services, extensions, and compliance tools. pgcomply minimizes this footprint by running entirely inside PostgreSQL with zero external dependencies.