GDPR Art.90 & Art.91 — Professional Secrecy and Religious Organizations: Developer Guide (2026)

Post #453 in the sota.io EU Cyber Compliance Series

Articles 90 and 91 are among the least-discussed provisions in the GDPR — and among the most operationally significant for developers building software for lawyers, doctors, clergy, journalists, or religious communities. They create two structured derogations from the GDPR's standard supervisory access and rule-application framework.

Art.90 lets Member States block supervisory authorities from accessing data protected by professional secrecy obligations. Art.91 allows churches and religious associations with pre-existing comprehensive data protection rules to continue applying those rules — provided they operate under independent supervision equivalent to a public data protection authority.

Neither provision is a "get out of GDPR free" card. Both operate within the GDPR framework, modify specific enforcement mechanisms, and impose their own conditions. Software serving these sectors must understand exactly what they permit — and what they do not.

Art.90: Professional Secrecy — What It Actually Does

The full text:

"Member States may adopt rules to reconcile the right to the protection of personal data pursuant to this Regulation with the obligation of professional secrecy, where such obligation is necessary to reconcile the right to the protection of personal data with the obligation of professional secrecy pursuant to Union or Member State law or rules established by national competent bodies, and processors under such an obligation shall, where necessary, be subject to the supervision of the competent national body."

Unpacked, Art.90 does three things:

1. Permits Member State rules that limit SA access. When a supervisory authority demands to inspect data held by a lawyer about a client, or a doctor about a patient, the Member State can have national rules restricting what the SA can directly access. The SA's investigation power bumps into professional secrecy rules rather than overriding them.

2. Requires those rules to be necessary. The limitation on supervisory access must be necessary to reconcile data protection with secrecy obligations. Member States cannot simply immunise entire sectors from GDPR enforcement using Art.90. The restriction must be targeted and proportionate.

3. Provides an alternative supervision mechanism. Where professional secrecy applies, processors under that obligation "shall, where necessary, be subject to the supervision of the competent national body." This means the bar association, medical council, or press council may supervise compliance rather than (or alongside) the public SA.

Who Art.90 Covers

Professional secrecy obligations arise from Union or Member State law, or from rules established by recognised professional bodies. The core categories:

The practical rule: if a German court can reject a subpoena of professional communications, Art.90 probably applies to that data.

What Art.90 Does NOT Do

Art.90 is not a blanket exemption. Developers must understand its limits:

The GDPR Still Applies

Professional secrecy does not suspend the GDPR. Lawyers still need:

• A lawful basis to process client data (typically Art.6(1)(b) — contract, or Art.6(1)(c) — legal obligation)
• A DPA with their cloud providers
• Technical and organisational measures (Art.32)
• A ROPA entry for client file management (Art.30)
• A breach notification obligation (Art.33/34)

Art.90 only affects supervisory authority access to the protected data. Everything else still applies.

Data Subjects Still Have Rights

Art.90 does not suspend data subject rights. A client can still exercise:

• Art.15 access rights to their own data
• Art.17 erasure rights (subject to conflicting legal obligations)
• Art.20 portability rights

The professional has rights against the SA, not rights against the data subject.

Art.90 is Member State Optional

Not every EU country has implemented Art.90 rules. Germany has (Bundesdatenschutzgesetz § 29a and professional-order statutes). France, Austria, and the Netherlands have their own implementations. If you build pan-EU legal tech, you cannot assume uniform Art.90 rules — check each jurisdiction.

Art.90 for Legal Tech Developers

If you build case management software, document management systems, or any SaaS for law firms, you face a specific architecture question: what can your own engineers access?

The Art.29 + Art.90 Intersection

Art.29 (covered in Post #451) requires processor employees to act only on documented controller instructions. When the data involved is protected by professional secrecy, the processing instructions must explicitly address secrecy scope.

Your DPA with law firm clients should state:

1. What data categories are processed
2. What instruction scope your engineers have for support/maintenance access
3. That secrecy-protected data (client files, communications) is off-limits for unscoped access
4. What the procedure is when support requires access to secrecy-protected data (typically: client consent or anonymised access only)

Access Architecture for Legal Data

class LegalDataAccessController:
    """
    Art.29 + Art.90 compliant access model for legal SaaS.
    
    Professional secrecy data requires additional access gates
    beyond standard RBAC — instruction scope must be verified.
    """
    
    SECRECY_CATEGORIES = [
        "client_communications",
        "case_strategy_notes",
        "privileged_documents",
        "client_identity_confidential",
    ]
    
    def can_access(
        self,
        accessor_role: str,
        data_category: str,
        access_purpose: str,
        instruction_document: str | None,
    ) -> tuple[bool, str]:
        if data_category in self.SECRECY_CATEGORIES:
            if accessor_role in ("vendor_support", "vendor_engineer"):
                if not instruction_document:
                    return False, "Professional secrecy data: explicit instruction required (Art.29 + Art.90)"
                if access_purpose not in ("documented_support_request", "client_authorised"):
                    return False, f"Purpose '{access_purpose}' not in scope for secrecy-protected data"
        
        # Standard RBAC check for non-secrecy data
        return self._standard_rbac_check(accessor_role, data_category, access_purpose)
    
    def _standard_rbac_check(self, role, category, purpose):
        # ... standard implementation
        return True, "Access granted"


# Audit log entry for every secrecy-data access attempt
def log_secrecy_access(
    accessor_id: str,
    client_matter_id: str,
    access_granted: bool,
    reason: str,
    instruction_ref: str | None,
):
    AuditLog.write({
        "event": "secrecy_data_access_attempt",
        "accessor": accessor_id,
        "matter": client_matter_id,
        "granted": access_granted,
        "reason": reason,
        "instruction_ref": instruction_ref,
        "art90_relevant": True,
    })

The Breach Notification Problem

If professional secrecy data is involved in a breach, Art.33/34 obligations remain — but Art.90 creates a tension. Notifying the SA about a breach may require disclosing the existence of a client relationship that is itself protected by professional secrecy.

The solution most bar associations have reached: notification goes to the bar association (the "competent national body" under Art.90), which then decides what the public SA needs to know. Your breach notification process should route secrecy-data breaches through this body, not directly to the SA, unless your jurisdiction's Art.90 rules say otherwise.

def notify_breach(breach: DataBreach, involves_secrecy_data: bool) -> None:
    if involves_secrecy_data:
        # Route to professional body, not directly to SA
        # Confirm jurisdiction's Art.90 implementation first
        notify_professional_body(breach, body="bar_association")
        # SA notification via professional body if required
    else:
        notify_sa_directly(breach)

Art.91: Religious Organizations — The GDPR Within a GDPR

Art.91 is structurally different from Art.90. While Art.90 modifies supervisory access, Art.91 allows entire alternative data protection frameworks to operate for churches:

"Where in a Member State, churches and religious associations or communities apply, at the time of entry into force of this Regulation, comprehensive rules relating to the protection of natural persons with regard to processing, such rules may continue to apply, provided that they are brought into line with this Regulation."

Art.91(2) adds the supervision requirement:

"Churches and religious associations which apply comprehensive rules in accordance with paragraph 1 of this Article shall be subject to the supervision of an independent supervisory authority, which may be a specific one, provided that it fulfils the conditions laid down in Chapter VI of this Regulation."

What This Means in Practice

Art.91 is primarily relevant in Germany, Austria, and Italy — countries where the Catholic Church, Protestant churches, and Jewish communities had comprehensive internal data protection rules before the GDPR came into force in 2018.

Germany: Both the Catholic Church (KDO — Kirchliche Datenschutzordnung) and the Protestant Church (DSG-EKD — Datenschutzgesetz der Evangelischen Kirche in Deutschland) operate their own data protection regimes. These are administered by internal supervisory bodies:

• Catholic: Der Beauftragte für den Datenschutz der Deutschen Bischofskonferenz + regional Kirchliche Datenschutzbeauftragte
• Protestant: Datenschutzbeauftragte der EKD

These bodies must apply GDPR-equivalent rules and must be genuinely independent — they cannot be subordinate to the very church leadership they supervise.

Art.91 in Software Terms

If you build a church management system (ChMS — Gemeindeverwaltungssoftware), your compliance picture changes:

The critical takeaway: you need jurisdiction-specific DPA templates for church clients. A standard GDPR DPA that names the national SA as the supervisory authority is wrong — it should name the relevant Kirchlicher Datenschutzbeauftragter.

Religious Belief Data: The Art.9 Overlay

Independent of Art.91, religious belief data is always a special category under Art.9(1). Processing religious affiliation, attendance records, sacramental participation, or pastoral care notes requires explicit consent or Art.9(2)(d) (not-for-profit body with religious aim, members/former members, or persons in regular contact with it — subject to appropriate safeguards, no third-party disclosure without consent).

For a church management system, the primary lawful basis for processing member data is typically Art.9(2)(d). For a SaaS vendor processing that same data as a processor, you need:

1. A DPA (standard Art.28 obligation)
2. The DPA must comply with the applicable church data protection law (not just GDPR)
3. Sub-processors must be church-law-compliant, not just GDPR-compliant

from dataclasses import dataclass
from enum import Enum

class DataProtectionRegime(Enum):
    GDPR_STANDARD = "gdpr"
    CHURCH_CATHOLIC_DE = "kdo_de"       # Kirchliche Datenschutzordnung
    CHURCH_PROTESTANT_DE = "dsgehkd_de" # Datenschutzgesetz EKD
    CHURCH_AT = "dsgk_at"               # Datenschutzgesetz Kirchen Österreich

@dataclass
class ClientComplianceProfile:
    client_id: str
    regime: DataProtectionRegime
    supervisory_authority: str
    dpa_template_id: str
    special_category_basis: str | None  # Art.9(2) paragraph if applicable

def get_compliance_profile(client_sector: str, jurisdiction: str) -> ClientComplianceProfile:
    """
    Determine the applicable compliance framework for a given client.
    Art.90 + Art.91 create sector-specific requirements.
    """
    if client_sector == "catholic_church" and jurisdiction == "DE":
        return ClientComplianceProfile(
            client_id="...",
            regime=DataProtectionRegime.CHURCH_CATHOLIC_DE,
            supervisory_authority="Kirchlicher_Datenschutzbeauftragter_DE",
            dpa_template_id="kdo_dpa_v3",
            special_category_basis="Art.9(2)(d)",
        )
    elif client_sector == "law_firm":
        return ClientComplianceProfile(
            client_id="...",
            regime=DataProtectionRegime.GDPR_STANDARD,
            supervisory_authority="Landesbeauftragter_fuer_Datenschutz",
            dpa_template_id="standard_gdpr_dpa_v2",
            special_category_basis=None,
        )
    # ... etc.

Sotrender: GDPR Art.90 + Art.91 in a SaaS Context

For Lawyers and Legal Tech

If you're a SaaS vendor serving law firms:

1. Your DPA must address secrecy scope. State explicitly what your support engineers can and cannot access. "Support engineers have no access to client matter data" or "access requires partner-level client authorisation."

2. Encryption at the field level matters more than at the database level. If the lawyer's client communications are encrypted with a key the lawyer controls (not you), your engineers literally cannot access the data even if compelled. This is the strongest Art.90-compatible design.

3. Jurisdiction clauses are critical. Art.90 implementation varies by Member State. Your DPA should specify which national law's Art.90 rules apply, and your breach notification process should name the relevant professional body by jurisdiction.

4. Sub-processor lists must be reviewable. If a law firm client asks "does anyone else touch our client data?", you must be able to answer with your current sub-processor list. Standard GDPR requirement, but higher stakes under Art.90.

For Church and Religious Community Software

1. Use the correct DPA template. German Catholic diocese clients → KDO DPA. German Protestant clients → DSG-EKD DPA. Standard GDPR DPA is technically wrong and may create compliance gaps.

2. Your SA contact differs. When you receive a data subject request routed through a church member, the governing authority for disputes is the Kirchlicher Datenschutzbeauftragter, not the BfDI or Landesbehörde.

3. Art.9(2)(d) is your primary lawful basis — not consent. Church membership data processed by a church for internal purposes (pastoral care, contributions, sacramental records) runs on Art.9(2)(d). You don't need explicit consent for processing that is inherent to the membership relationship. Third-party disclosure (e.g., your analytics vendor receiving membership lists) requires explicit consent or another Art.9(2) basis.

4. sota.io server location matters here too. A church data processor running on EU infrastructure avoids the CLOUD Act problem that comes with AWS/GCP/Azure. Church data protection laws in Germany and Austria explicitly require processing within jurisdictions with adequate protection — US-parent cloud providers create a structural tension with Art.91 compliance.

Art.90 + Art.91 Compliance Checklist

For Legal SaaS

• DPA explicitly addresses professional secrecy scope and engineer access restrictions
• Access controls prevent unscoped access to secrecy-protected data categories
• Audit log captures every access attempt to secrecy-categorised data with purpose
• Breach notification procedure routes secrecy-data breaches through professional body (not direct SA notification)
• Sub-processor list reviewed for jurisdiction-by-jurisdiction Art.90 compatibility
• Field-level encryption considered for highest-sensitivity client communications

For Church/Religious Community SaaS

• Correct DPA template for applicable church data protection law
• Supervisory authority correctly named (church body, not public SA)
• Art.9(2)(d) lawful basis documented in ROPA
• Third-party disclosure restrictions enforced (no sharing with analytics/ad vendors without explicit consent)
• Sub-processors limited to EU-jurisdiction providers where church law requires
• Data subject rights requests routed through church data protection contact

Where sota.io Fits

Professional secrecy and church data protection share a common thread: they require processing infrastructure that is not subject to CLOUD Act or equivalent third-country government access regimes.

A law firm's client data on AWS (a US company) is theoretically reachable via CLOUD Act national security letters — regardless of whether the servers are in Frankfurt. The same applies to church member data: the processing agreement with a US-parent cloud provider creates a structural conflict with Art.91 compliance and church data protection laws that require processing in adequately protected jurisdictions.

sota.io runs on EU-owned infrastructure with no US-parent entity. For legal tech and church management software, this is not a marketing point — it is a compliance requirement that simplifies DPA negotiations and eliminates the CLOUD Act exposure that GDPR Art.90 and church data protection laws implicitly prohibit.

Key Takeaways

• Art.90 allows Member States to protect professional secrecy data from supervisory authority inspection — but does not exempt lawyers, doctors, or journalists from GDPR compliance. It only modifies the enforcement mechanism.
• Art.91 allows churches with pre-existing comprehensive data protection rules to continue applying them — provided those rules are GDPR-compatible and administered by a genuinely independent supervisory body.
• For developers: the DPA template, the named supervisory authority, the lawful basis for Art.9 data, and the sub-processor selection all change depending on whether you serve regulated professionals (Art.90) or religious organisations (Art.91).
• Field-level encryption under client-controlled keys is the strongest technical implementation of Art.90 — it makes supervisory access to secrecy-protected data technically impossible even if legally demanded.
• EU-resident infrastructure (no US-parent entity) eliminates the CLOUD Act tension that complicates Art.90 and Art.91 compliance.

Next in the GDPR series: Art.92–99 — Final Provisions, Implementing Acts, Entry into Force, and Repeal of the 1995 Directive.