Regulatory Compliance Overview
Regulatory compliance for IT encompasses the legal and regulatory obligations that govern how organisations collect, process, store, and protect information using technology systems. Mission-driven organisations face a distinctive compliance landscape shaped by multi-jurisdictional operations, diverse funding sources, and the sensitive nature of beneficiary data. This framework provides the structure for identifying which regulations apply, implementing appropriate controls, monitoring ongoing compliance, and demonstrating adherence to auditors and regulators.
- Regulatory obligation
- A requirement imposed by law, regulation, or authoritative standard that an organisation must satisfy. Obligations carry legal force and non-compliance results in defined penalties.
- Compliance control
- A specific measure implemented to satisfy one or more regulatory obligations. Controls take the form of policies, procedures, technical configurations, or organisational structures.
- Compliance evidence
- Documentation demonstrating that a control exists, operates effectively, and satisfies its associated obligation. Evidence includes logs, attestations, test results, and procedural records.
- Regulatory scope
- The boundaries within which a regulation applies, determined by factors including geographic location, data subject residence, organisational activities, and sector classification.
- Supervisory authority
- The government body empowered to enforce a specific regulation, conduct investigations, and impose penalties. Different regulations designate different authorities.
The compliance landscape
Mission-driven organisations operate within a compliance environment that differs substantially from commercial enterprises. The combination of multi-country operations, grant-funded activities, and handling of vulnerable population data creates overlapping regulatory requirements that must be navigated simultaneously.
The regulatory framework affecting IT operations divides into four categories. Data protection regulations govern the collection, processing, and storage of personal information. The General Data Protection Regulation (GDPR) applies to any organisation processing data of individuals in the European Economic Area, regardless of where the organisation is headquartered. Similar frameworks exist in over 130 countries, with varying requirements and enforcement mechanisms. Accessibility regulations mandate that digital services remain usable by people with disabilities. The European Accessibility Act, UK Equality Act, and US Section 508 impose specific technical standards on websites, applications, and documents. Sector-specific regulations apply to organisations based on their activities: health data regulations for medical programmes, financial regulations for cash transfer operations, and child protection requirements for youth-focused services. Jurisdictional regulations arise from the countries where an organisation operates, maintains offices, or employs staff, covering areas from employment data to tax records.
+------------------------------------------------------------------+| REGULATORY CATEGORIES |+------------------------------------------------------------------+| || +----------------------------+ +----------------------------+ || | DATA PROTECTION | | ACCESSIBILITY | || | | | | || | - GDPR (EU/EEA) | | - European Accessibility | || | - UK GDPR | | Act (EAA) | || | - LGPD (Brazil) | | - UK Equality Act 2010 | || | - POPIA (South Africa) | | - US Section 508 | || | - PDPA (Kenya, Thailand) | | - WCAG 2.1 Level AA | || | - DPDP (India) | | - EN 301 549 | || | | | | || +----------------------------+ +----------------------------+ || || +----------------------------+ +----------------------------+ || | SECTOR-SPECIFIC | | JURISDICTIONAL | || | | | | || | - Health: HIPAA (US), | | - Employment records | || | medical device regs | | - Tax documentation | || | - Finance: PCI-DSS, | | - Corporate registration | || | payment regulations | | - Telecommunications | || | - Children: COPPA (US), | | - Import/export controls | || | Age Appropriate Design | | - Local data residency | || | | | | || +----------------------------+ +----------------------------+ || |+------------------------------------------------------------------+Figure 1: Four categories of IT-related regulatory obligations
The interaction between these categories creates complexity. An organisation running health programmes in Kenya while headquartered in the UK and receiving EU funding simultaneously faces UK GDPR for staff data, Kenya’s Data Protection Act for beneficiary data, EU accessibility requirements for public-facing content, health sector data regulations, and donor-specific compliance requirements. Each regulation has its own supervisory authority, enforcement mechanism, and penalty structure.
Determining regulatory applicability
Regulatory applicability depends on specific triggers rather than general organisational characteristics. Each regulation defines the conditions under which it applies, and organisations must evaluate their activities against these triggers to build an accurate compliance scope.
The GDPR applies when an organisation is established in the EEA, or when it offers goods or services to individuals in the EEA, or when it monitors the behaviour of individuals in the EEA. Establishment means having a stable arrangement for exercising activity, not merely having a bank account or contractor. Offering goods or services requires intent to serve EEA residents, evidenced by factors like EEA languages, euro pricing, or marketing directed at EEA countries. Behavioural monitoring includes website tracking, profiling, and location-based services. An organisation with no EEA establishment that maintains a website accessible from the EEA does not trigger GDPR unless the site specifically targets EEA visitors.
+--------------------------------------------------------------------+| GDPR APPLICABILITY ASSESSMENT |+--------------------------------------------------------------------+| || Organisation activities || | || +---------------+---------------+ || | | || v v || +--------+--------+ +--------+--------+ || | Established in | | Not established | || | EEA? | | in EEA | || +--------+--------+ +--------+--------+ || | | || Yes | | || v v || +--------+--------+ +--------+--------+ || | GDPR applies to | | Offers goods/ | || | all processing | | services to EEA | || | in context of | | individuals? | || | establishment | +--------+--------+ || +-----------------+ | || +------------+------------+ || | | || Yes | | No || v v || +--------+--------+ +--------+--------+ || | GDPR applies to | | Monitors EEA | || | that processing | | individual | || +-----------------+ | behaviour? | || +--------+--------+ || | || +------------+----+ || | | || Yes | | No || v v || +--------+------+ +-------+--+ || | GDPR applies | | GDPR does| || | to monitoring | | not apply| || +---------------+ +----------+ || |+--------------------------------------------------------------------+Figure 2: GDPR applicability decision tree
Accessibility regulations follow different applicability logic. The European Accessibility Act applies to products and services placed on the EU market from 28 June 2025, covering websites, mobile applications, e-commerce, and electronic communications. The UK Equality Act requires reasonable adjustments to avoid disadvantaging disabled people, applying to all service providers regardless of size. WCAG (Web Content Accessibility Guidelines) functions as a technical standard rather than a regulation, but multiple regulations reference WCAG 2.1 Level AA as the required conformance level. Organisations must determine which accessibility regulations apply based on where they provide digital services, not where they are headquartered.
Sector-specific regulations attach to activities rather than organisations. Processing health data triggers health data regulations in the relevant jurisdiction. Operating cash transfer programmes triggers payment regulations and potentially anti-money-laundering requirements. Working with children triggers child protection data requirements. An organisation may face different sector regulations for different programmes, requiring programme-level compliance mapping rather than a single organisational assessment.
Compliance management framework
A compliance management framework provides the structure for maintaining ongoing regulatory adherence across an organisation. The framework operates through four interconnected components: obligation identification, control implementation, monitoring and testing, and evidence management.
+---------------------------------------------------------------------+| COMPLIANCE MANAGEMENT FRAMEWORK |+---------------------------------------------------------------------+| || +----------------+ +----------------+ +----------------+ || | | | | | | || | OBLIGATION | | CONTROL | | MONITORING | || | IDENTIFICATION|----->| IMPLEMENTATION|----->| AND TESTING | || | | | | | | || | - Regulatory | | - Policies | | - Control | || | inventory | | - Procedures | | testing | || | - Applicability| | - Technical | | - Compliance | || | assessment | | controls | | metrics | || | - Obligation | | - Training | | - Exception | || | register | | - Assignment | | tracking | || | | | | | | || +-------+--------+ +-------+--------+ +-------+--------+ || | | | || | | | || | +-------v--------+ | || | | | | || +-------------->| EVIDENCE |<-------------+ || | MANAGEMENT | || | | || | - Documentation || | - Retention | || | - Audit trail | || | - Retrieval | || | | || +----------------+ || |+---------------------------------------------------------------------+Figure 3: Compliance management framework components
Obligation identification begins with building a regulatory inventory listing all regulations potentially applicable to the organisation. For each regulation, an applicability assessment determines whether the organisation’s activities trigger coverage. Confirmed obligations enter an obligation register that maps specific requirements to responsible parties and implementation status. The register requires annual review and event-triggered updates when the organisation enters new jurisdictions, launches new programme types, or changes data processing activities.
A worked example illustrates the obligation identification process. An organisation headquartered in London operates programmes in Kenya and Jordan, receives funding from the UK government and UN agencies, and maintains a public website. The regulatory inventory includes UK GDPR, Kenya Data Protection Act 2019, Jordan’s pending data protection framework, UK Equality Act, European Accessibility Act (for EU-facing content), and sector-specific requirements based on programme activities. The applicability assessment confirms UK GDPR applies to all processing (UK establishment), Kenya DPA applies to beneficiary data processing in Kenya, the Equality Act applies to all digital services, and donor compliance requirements apply to funded activities. Each confirmed regulation generates specific obligations: UK GDPR produces approximately 50 distinct obligations covering lawful basis, data subject rights, security measures, breach notification, and international transfers.
Control implementation translates obligations into operational measures. Each obligation requires one or more controls to achieve compliance. Controls take three forms: policy controls establish rules and requirements, procedural controls define how activities are performed, and technical controls enforce requirements through system configuration. Effective control design considers both the regulatory requirement and the organisation’s operational context. A data subject access request obligation might be satisfied by a policy establishing the 30-day response requirement, a procedure defining how requests are received, verified, processed, and responded to, and a technical control providing search capability across relevant systems.
Control mapping links each obligation to its implementing controls and establishes ownership. The control owner bears responsibility for control operation, testing, and remediation of deficiencies. For organisations with limited IT capacity, a single person may own all IT-related controls. Larger organisations distribute ownership across functional areas. Regardless of structure, documented ownership prevents gaps where no one monitors a control’s effectiveness.
Monitoring and testing verifies that controls operate as designed and achieve their intended effect. Monitoring divides into continuous monitoring through automated tools and metrics, and periodic testing through scheduled assessments. The monitoring approach varies by control type and risk level.
| Control risk level | Monitoring frequency | Testing frequency |
|---|---|---|
| Critical (breach notification, access controls) | Continuous automated | Quarterly manual |
| High (encryption, backup, retention) | Weekly automated | Semi-annual manual |
| Medium (training completion, policy review) | Monthly automated | Annual manual |
| Low (documentation, minor procedures) | Quarterly review | Annual manual |
Automated monitoring covers controls with measurable outputs: access reviews completed, backup success rates, certificate expiry dates, training completion percentages. Manual testing covers controls requiring judgement: policy adequacy, procedure effectiveness, exception handling appropriateness. Testing should include negative testing that verifies controls prevent non-compliant outcomes, not merely positive testing that confirms compliant paths work.
Evidence management creates the documentary foundation for demonstrating compliance. Regulators, auditors, and donors require evidence that controls exist, operate consistently, and achieve required outcomes. Evidence falls into three categories: design evidence showing what controls exist (policies, procedures, system configurations), operating evidence showing controls function (logs, reports, attestations), and effectiveness evidence showing controls achieve outcomes (test results, metrics, incident records).
Evidence retention periods depend on the underlying regulation. GDPR requires demonstration of compliance for as long as processing occurs plus the limitation period for regulatory action, typically 5-6 years. Financial regulations often require 7-year retention. The evidence management system must track retention requirements by evidence type and ensure systematic destruction when retention periods expire.
Key regulatory frameworks
General Data Protection Regulation
The GDPR establishes comprehensive requirements for processing personal data. The regulation applies to any organisation processing personal data of individuals in the European Economic Area, with extraterritorial reach extending to non-EEA organisations that offer services to EEA individuals or monitor their behaviour. Penalties reach up to 4% of annual global turnover or €20 million, whichever is higher.
The regulation’s core requirements cluster around six principles: lawfulness, fairness, and transparency in processing; purpose limitation confining use to specified purposes; data minimisation restricting collection to what is necessary; accuracy maintaining correct and current data; storage limitation retaining data only as long as necessary; and integrity and confidentiality ensuring appropriate security. Each principle generates specific compliance obligations.
Lawful basis requirements demand that every processing activity have a valid legal ground before processing begins. The six lawful bases are consent, contract performance, legal obligation, vital interests, public task, and legitimate interests. Mission-driven organisations most commonly rely on legitimate interests for operational processing, consent for marketing and fundraising, and legal obligation for employment and regulatory requirements. Legitimate interests requires a three-part test: identifying the legitimate interest, demonstrating processing is necessary for that interest, and balancing against data subject rights. Documentation of this assessment must exist for each legitimate interests processing activity.
Data subject rights create obligations to respond to individual requests within defined timeframes. Access requests require response within one month, providing a copy of personal data and information about processing. The right to erasure (deletion) applies when data is no longer necessary, consent is withdrawn, or processing was unlawful. Portability rights allow individuals to receive their data in machine-readable format and transmit it elsewhere. Each right has conditions and exceptions that require careful assessment before responding.
International transfer restrictions limit movement of personal data outside the EEA. Transfers to countries with adequacy decisions (UK, Japan, South Korea, Argentina, and others) proceed without additional safeguards. Transfers to other countries require mechanisms such as Standard Contractual Clauses, Binding Corporate Rules, or explicit consent. Following the Schrems II judgement, transfers to the United States require additional assessment of US surveillance law applicability and supplementary measures where risks are identified.
Accessibility requirements
Accessibility regulations require that digital services remain usable by people with disabilities. The technical standard underlying most regulations is WCAG 2.1, which defines success criteria across four principles: perceivable, operable, understandable, and robust. Level AA conformance represents the standard required by most regulations, comprising 50 success criteria that websites and applications must satisfy.
The European Accessibility Act applies from 28 June 2025 to products and services placed on the EU market. Covered digital services include websites, mobile applications, e-commerce, ticketing and check-in services, and electronic communications. Organisations providing services to EU users must ensure those services meet accessibility requirements regardless of where the organisation is located.
The UK Equality Act 2010 requires service providers to make reasonable adjustments to avoid placing disabled people at a substantial disadvantage. Unlike prescriptive technical standards, reasonable adjustments require contextual assessment of what is achievable for each organisation. However, courts and regulators increasingly reference WCAG 2.1 Level AA as defining reasonable web accessibility.
Accessibility compliance requires both technical implementation and ongoing maintenance. Initial conformance requires testing against WCAG criteria using a combination of automated tools (which catch approximately 30% of issues) and manual assessment (required for the remaining 70%). An accessibility statement must document conformance level, known issues, and remediation plans. Ongoing compliance requires accessibility testing in development workflows, regular audits, and a mechanism for users to report barriers.
Sector-specific frameworks
Organisations operating in specific sectors face additional regulatory requirements based on their activities.
Health data processing triggers specific frameworks in many jurisdictions. In the UK, the Caldicott Principles and NHS Data Security and Protection Toolkit apply to organisations handling NHS data. In the US, HIPAA applies to covered entities and their business associates handling protected health information. The EU Medical Device Regulation affects software used in medical contexts. These frameworks layer additional requirements on top of general data protection obligations, typically mandating specific security controls, audit trails, and access restrictions.
Financial services and payment processing attract regulation from multiple angles. PCI-DSS (Payment Card Industry Data Security Standard) applies to any organisation accepting, processing, storing, or transmitting cardholder data. Anti-money-laundering regulations apply to organisations conducting financial transactions above defined thresholds. Cash transfer programming in humanitarian contexts engages both payment regulations and donor-specific requirements around financial controls and beneficiary verification.
Child-focused activities trigger enhanced protection requirements. The UK Age Appropriate Design Code requires services likely to be accessed by children to implement 15 standards covering data minimisation, default privacy settings, and geolocation restrictions. COPPA in the United States requires verifiable parental consent before collecting personal information from children under 13. Child safeguarding frameworks require specific data protection measures for case management systems handling child protection information.
Compliance roles and responsibilities
Effective compliance requires clear role definition across the organisation. The allocation of compliance responsibilities varies with organisational size and structure, but certain functions must exist regardless of how they are staffed.
Executive accountability rests with the board or senior leadership team, which bears ultimate responsibility for compliance. This accountability cannot be delegated, though operational responsibility is assigned to functional roles. Executive responsibilities include approving compliance policies, ensuring adequate resourcing, receiving compliance reports, and making decisions on significant compliance matters.
Compliance coordination functions as the operational centre for compliance management. In larger organisations, a dedicated compliance function or officer fills this role. In smaller organisations, this function combines with legal, risk management, or finance roles. The coordinator maintains the obligation register, monitors compliance status across the organisation, coordinates audit and assessment activities, and escalates significant issues to executive leadership. For GDPR compliance, organisations meeting the designation criteria must appoint a Data Protection Officer with specific independence and reporting requirements.
Control ownership assigns responsibility for specific controls to individuals or teams. Control owners ensure their assigned controls operate effectively, conduct or coordinate testing, address deficiencies, and maintain evidence. IT-related controls typically fall under IT leadership, with specific controls assigned to relevant technical staff. For instance, the security team owns access control and encryption controls, while operations staff own backup and availability controls.
Operational compliance encompasses all staff whose activities affect compliance outcomes. Every employee who handles personal data, accesses systems, or interacts with beneficiaries has compliance responsibilities embedded in their role. These responsibilities are communicated through policies, reinforced through training, and verified through monitoring.
+------------------------------------------------------------------+| COMPLIANCE ROLE STRUCTURE |+------------------------------------------------------------------+| || +--------------------+ || | BOARD / | || | EXECUTIVE TEAM | || | | || | - Ultimate | || | accountability | || | - Policy approval | || | - Resource | || | allocation | || +---------+----------+ || | || | Reports to || v || +---------+----------+ || | COMPLIANCE | || | COORDINATOR | || | (or DPO) | || | | || | - Obligation | || | management | || | - Status | || | monitoring | || | - Audit | || | coordination | || +---------+----------+ || | || +---------------+-----------------+ || | | | || v v v || +--------+----+ +-------+-------+ +------+------+ || | CONTROL | | CONTROL | | CONTROL | || | OWNER: | | OWNER: | | OWNER: | || | Security | | IT Ops | | Data Mgmt | || | | | | | | || | - Access | | - Backup | | - Retention | || | - Encryption| | - Availability| | - Quality | || | - Incident | | - Change | | - Subject | || | response | | control | | rights | || +-------------+ +---------------+ +-------------+ || || +-------------------------------------------------------------+ || | ALL STAFF | || | | || | - Policy adherence - Data handling - Incident | || | - Training completion - Access use - reporting | || +-------------------------------------------------------------+ || |+------------------------------------------------------------------+Figure 4: Compliance role structure and reporting relationships
Audit preparation
Regulatory audits, whether conducted by supervisory authorities, donors, or external auditors, require systematic preparation. The audit lifecycle spans pre-audit preparation, audit execution, and post-audit remediation.
Pre-audit preparation begins when audit notification is received or when internal planning identifies an upcoming assessment. The preparation phase involves confirming audit scope (which regulations, time periods, and systems), gathering required evidence, briefing relevant staff, and preparing the physical or virtual audit environment. Evidence gathering follows the obligation register, collecting documentation for each in-scope control. Gaps identified during preparation require either rapid remediation or documented explanations with remediation plans.
A compliance evidence package for a GDPR audit typically includes: the data protection policy and associated procedures; records of processing activities for all in-scope processing; lawful basis assessments and, where applicable, legitimate interests assessments; privacy notices and consent records; data subject request logs and response samples; international transfer documentation including SCCs and transfer impact assessments; security control documentation and test results; training records showing completion rates and content; incident logs and breach notification records where applicable; and third-party agreements including Data Processing Agreements.
Audit execution requires designated staff availability, access arrangements for auditors, and a coordination point for information requests. Auditors typically work from an initial document request, followed by interviews with key staff, system demonstrations, and sampling of operational records. Responses to audit queries should be factual and complete, neither volunteering unrelated information nor withholding relevant details.
Post-audit remediation addresses findings through a formal management response. Each finding requires acknowledgement or challenge, root cause analysis, remediation action, responsible party assignment, and target completion date. Findings typically categorise by severity, with critical findings requiring immediate attention and advisory findings entering normal improvement planning. Remediation tracking continues until all agreed actions complete, with evidence retained demonstrating closure.
Implementation considerations
For organisations with limited IT capacity
Small organisations or those with a single IT person face the same regulatory obligations as larger organisations but must implement compliance with constrained resources. The pragmatic approach focuses on high-risk areas first and builds systematic compliance over time.
Start with a minimal compliance foundation: document what personal data the organisation processes and why, implement core security controls (access management, encryption, backup), create essential policies (data protection, acceptable use, information security), and establish basic procedures for data subject requests and incidents. This foundation addresses the highest-risk areas and creates a structure for expansion.
Leverage existing resources where possible. Sector bodies, umbrella organisations, and regulatory guidance provide templates and frameworks that reduce development effort. The UK Information Commissioner’s Office publishes toolkits for small organisations. Data protection authorities across jurisdictions provide similar resources. Using established templates ensures coverage of required elements and accelerates implementation.
Accept that some compliance activities occur reactively rather than proactively. When resources are limited, addressing a data subject request when received takes precedence over building elaborate request management systems in advance. Document procedures as they develop, creating operational documentation through actual practice rather than theoretical process design.
For organisations with established IT functions
Organisations with dedicated IT and compliance capacity can implement comprehensive compliance programmes. The challenge shifts from basic coverage to efficiency, integration, and continuous improvement.
Integrate compliance into operational workflows rather than treating it as a separate activity. Security controls should satisfy multiple regulatory requirements simultaneously: access management addresses GDPR security requirements, PCI-DSS access controls, and donor audit requirements through a single implementation with appropriate documentation for each audience. Policy frameworks should map to multiple regulations, with a single information security policy satisfying requirements from data protection, sector regulations, and donor frameworks.
Automate compliance monitoring where possible. Continuous control monitoring through security tools, identity management systems, and operational dashboards reduces manual assessment effort and provides real-time visibility into compliance status. Automated evidence collection captures logs, reports, and attestations without manual intervention. Dashboard reporting surfaces compliance metrics to leadership without requiring manual report compilation.
Invest in compliance tooling appropriate to scale. Governance, risk, and compliance (GRC) platforms provide centralised obligation management, control tracking, evidence repositories, and audit support. For mid-sized organisations, spreadsheet-based registers and file-based evidence storage may suffice. The decision to adopt dedicated tooling depends on the volume of obligations, frequency of audits, and available resources for tool administration.
For federated and multi-entity organisations
Organisations with autonomous country offices, affiliates, or subsidiaries face additional complexity in compliance management. Each entity may have its own legal personality, regulatory obligations, and operational systems while sharing brand, standards, and sometimes data with the broader organisation.
The compliance framework must accommodate both shared standards and local variation. Global policies establish minimum requirements applicable across all entities, while local policies address jurisdiction-specific obligations. The global framework defines which elements require consistency (security baselines, breach notification processes, core training requirements) and which allow local determination (local lawful basis selection, local authority notification procedures).
Data sharing between entities requires explicit mechanisms. Transfers between legal entities constitute third-party sharing under most data protection frameworks, requiring appropriate agreements and safeguards. International transfers between entities in different jurisdictions require the same mechanisms as transfers to external parties: adequacy decisions, Standard Contractual Clauses, or other approved transfer tools.
Compliance reporting aggregates entity-level status into organisational views while maintaining entity accountability. Each entity reports compliance status through defined metrics and exception reporting. Central compliance functions consolidate reporting, identify systemic issues, and coordinate cross-entity improvements. This federated model respects entity autonomy while ensuring organisational visibility and consistent standards.