Compliance and Regulation

This section helps UK organisations translate legal, regulatory, contractual and assurance requirements into practical software controls. It is a navigation page, not a universal compliance checklist: the applicable position depends on the organisation, service, users, data and regulated activities.

Decision summary: Identify which laws, regulators, contracts and standards actually apply, then translate each obligation into controls and evidence.

The current governance position

For “Compliance and Regulation”, data-protection and communications rules should be mapped to the actual organisation, purposes, users, data and suppliers. Avoid universal statements about consent, retention, controller or processor status. Record the decision and review it when the service, law or guidance changes.

GDPR compliance checklist for web applications

General Data Protection Regulation compliance is not a one-off task completed before launch. It is a continuous obligation that affects how a web application is designed, built, operated and eventually decommissioned. For business owners and operations managers buying or commissioning software, the practical question is not whether GDPR applies — it does — but whether the system has been built to satisfy its core requirements.

The following points represent the areas a web application should address. This is not legal advice, and the current guidance from the Information Commissioner's Office should be consulted for definitive requirements.

• Lawful basis for processing: Every data processing activity must map to a lawful basis under UK GDPR. A CRM storing customer contact details for contract performance is different from a portal analysing user behaviour for marketing. The basis should be documented, not assumed.
• Data minimisation: The application should collect only what is necessary for its stated purpose. If a registration form asks for a job title that is never used in any workflow, that is a compliance gap.
• Subject access request capability: Users must be able to request a copy of their personal data. If the system scatters data across multiple modules without a single view of a person, fulfilling these requests becomes slow and error-prone.
• Right to erasure: The application needs a mechanism to delete a user's personal data without breaking referential integrity in the database. This usually requires careful data modelling from the outset.
• Data portability: Where technically feasible, users should be able to receive their data in a structured, machine-readable format.
• Breach notification procedures: The system should support the detection and logging of security incidents, and the business must have a process to notify the ICO within the required timeframe where necessary.
• Records of processing activities: The business, not the software supplier, is responsible for maintaining these records, but the application's data flows and storage locations must be understood well enough to document them accurately.
• International transfers: If personal data leaves the UK, appropriate safeguards must be in place. This is particularly relevant for SaaS products using cloud infrastructure or sub-processors based outside the UK.

A common mistake is treating GDPR as a design-phase checkbox and then ignoring it during feature development. Every new module, integration or data field can introduce a new processing activity that needs its own lawful basis and documentation.

UK data protection act 2018: what software buyers need to know

The UK Data Protection Act 2018 sits alongside the UK GDPR and provides the domestic legal framework. For software buyers, the DPA 2018 matters because it defines specific exemptions, lawful bases and enforcement provisions that differ in detail from the EU's equivalent legislation.

When purchasing or commissioning a web application, several practical points arise from this legislation:

• Controller or processor status: The commissioning business may be a controller for its own purposes, while a supplier may be a processor, independent controller or joint controller depending on the processing. Roles must be mapped by purpose, instructions and actual decision-making rather than assumed from the commercial label. A supplier's statement that it is "GDPR compliant" does not establish the customer's role or remove either party's responsibilities.
• Contractual requirements: The DPA 2018 and UK GDPR require that contracts with processors include specific terms. A standard software development agreement that does not address data processing obligations is unlikely to be sufficient.
• Exemptions: The DPA 2018 contains exemptions for certain processing activities, such as those related to journalism, research or regulatory functions. These are narrow and sector-specific. Assuming an exemption applies without legal review is a risk.
• Liability: If a processor's failure causes a data breach, the controller remains liable to the data subject. The controller's recourse is against the processor under the contract. This makes the terms of that contract directly consequential.

Buyers should ask their legal advisers to review the data protection terms in any software contract, not just the commercial clauses. A development quote that is silent on data processing is a signal that the conversation about compliance has not yet happened.

How to handle cookie consent in a web application

Cookie consent is often associated with marketing websites, but web applications use cookies and similar technologies extensively — for session management, authentication tokens, preference storage and analytics. The same legal requirements apply.

The PECR (Privacy and Electronic Communications Regulations) require that non-essential cookies are not placed on a user's device until they have given informed consent. The practical implementation in a web application involves several considerations:

• Categorise every cookie and local storage item: A web application typically uses strictly necessary cookies for security and session handling, which do not require consent. But analytics, feature flags, third-party integrations and preference storage may fall into categories that do.
• Consent must be active, not pre-ticked: A banner with pre-selected checkboxes does not constitute valid consent. The user must take a positive action.
• Granularity: Users should be able to accept or reject categories of cookies independently. Blocking all non-essential cookies should not break core application functionality, which means the application must be built to degrade gracefully when analytics or tracking cookies are absent.
• Record of consent: The business must be able to demonstrate when and what the user consented to. This requires storing consent records with timestamps, not just setting a cookie that says "accepted".
• Withdrawing consent: If a user later withdraws consent for a category of cookies, the application must stop setting those cookies on subsequent visits. This is straightforward for new sessions but requires the consent state to be checked on every page load.

A frequent oversight in web applications is the use of local storage or session storage as an alternative to cookies. PECR applies to equivalent technologies, not just cookies specifically. Development teams should audit all client-side storage mechanisms, not just the cookie jar.

Privacy by design in software development

Privacy by Design is a principle embedded in UK GDPR that requires data protection to be considered from the earliest stages of system design, not bolted on afterwards. For business owners commissioning software, this principle should shape the requirements and the development process itself.

In practice, Privacy by Design in a web application project means:

• Data protection impact assessments: For systems that involve systematic monitoring, large-scale processing or sensitive data categories, a DPIA should be completed before development begins. The assessment should inform technical decisions, not merely document them after the fact.
• Default settings: The application should default to the most privacy-protective configuration. If a portal can function without sharing user data with third parties, that should be the default, with opt-in for broader sharing.
• Data minimisation in the data model: The database schema should reflect only the data the application genuinely needs. Storing additional fields "in case they're useful later" is contrary to the principle and creates unnecessary risk.
• Access controls: Personal data should be accessible only to users who need it for their role. A well-designed role-based access control system, planned at the requirements stage, is a direct expression of Privacy by Design.
• Pseudonymisation and encryption: Where appropriate, data should be pseudonymised so that it cannot be attributed to an individual without additional information held separately. Encryption at rest and in transit should be standard, not an optional upgrade.
• Retention limits: The application should support automated or semi-automated data retention policies. If data should be deleted after a certain period, the system should be capable of enforcing that, rather than relying on manual admin action.

When briefing a development team, asking "how will this feature affect our data map?" is more useful than asking "is this GDPR compliant?". The first question forces a specific technical answer. The second tends to produce a reassuring but unhelpful generalisation.

ISO 27001 and SOC 2: what they mean for software suppliers

When evaluating a SaaS supplier or a development agency that will handle personal data, certifications such as ISO 27001 and SOC 2 frequently appear in procurement conversations. Understanding what each actually covers helps buyers avoid treating a certificate as a guarantee.

ISO 27001 is an international standard for information security management systems. It certifies that an organisation has implemented a systematic approach to managing sensitive information, including policies, procedures and technical controls. It covers the supplier's own operations — how they manage access to their systems, how they handle incidents, how they train staff. It does not certify that a specific software product is secure, though a well-run ISMS should influence product quality.

SOC 2 is an auditing standard developed by the American Institute of CPAs. It evaluates an organisation's controls across five trust service criteria: security, availability, processing integrity, confidentiality and privacy. A SOC 2 Type II report covers the operational effectiveness of those controls over a defined period, which makes it more granular than a point-in-time certification.

For buyers, the practical distinctions matter:

• ISO 27001 is about the management system. SOC 2 is about the controls in operation.
• ISO 27001 is widely recognised in the UK and Europe. SOC 2 is more common in US-based SaaS vendors.
• Neither certification eliminates the need for the buyer to conduct their own due diligence on the specific product, data flows and contractual terms.
• Certifications can lapse. A certificate dated three years ago provides no current assurance. Buyers should verify that certification is current and check the scope — some certifications cover only part of an organisation's operations.

Asking a supplier for their latest SOC 2 report or ISO 27001 certificate is a reasonable starting point. Following up with questions about scope, exclusions and any qualifications noted in the audit report is where the useful information emerges.

Industry-specific compliance: FCA, CQC and others

Beyond general data protection law, many UK sectors have their own regulatory frameworks that impose specific requirements on the software systems used within them. A web application built for a financial services firm faces different constraints than one built for a healthcare provider, even if both are technically similar CRMs or portals.

Financial services (FCA): The Financial Conduct Authority expects firms to maintain accurate records, demonstrate compliance with client money rules where applicable, and keep audit trails that can withstand regulatory scrutiny. Software used in regulated activities may need to support specific reporting formats, mandatory data retention periods and controls around who can approve transactions. The FCA does not certify software, but it will examine the systems a firm uses as part of a supervisory visit.

Health and social care (CQC): The Care Quality Commission regulates the quality of care services. While it does not directly regulate software, it assesses how providers use information systems to deliver safe, effective care. Records systems must support accurate, contemporaneous documentation. Access controls must prevent unauthorised access to sensitive patient information. Integration with other health systems may be required in some contexts.

Other regulated sectors: Legal services, education, pharmaceuticals and government contracting each carry their own compliance expectations. The common thread is that regulators expect the business to demonstrate control over its information systems, not merely to have purchased a compliant product.

For buyers in regulated sectors, the key questions to address early in a software project are:

• Which regulatory obligations apply to the data and processes this system will handle?
• Does the regulator publish specific guidance on technology or record-keeping that affects our system design?
• What audit trail, reporting and access-control requirements must the system satisfy?
• Will our legal or compliance team need to review the system before it goes live?

Discovering regulatory requirements after a system is built is significantly more expensive than incorporating them into the initial requirements. If the development team does not ask about regulatory context, the buyer should raise it proactively.

How to write a privacy notice for a web application

A privacy notice — sometimes called a privacy policy — is the document that tells users what happens to their personal data. Under UK GDPR, it must be concise, transparent and written in clear language. For web applications, the privacy notice needs to reflect the specific functionality of the system, not generic boilerplate.

The following elements should be covered. The ICO's current guidance on privacy notices should be consulted for the definitive list and any recent changes:

• Identity and contact details of the controller: The legal entity responsible for the processing. For a SaaS product, this is the company providing the service, not the development agency that built it.
• Contact details of the data protection officer, if applicable: Not every business is required to appoint a DPO, but if one exists, their contact details must be included.
• Purposes of the processing: What the application does with personal data, stated specifically. "To improve our services" is too vague. "To send order status updates by email" is sufficiently specific.
• Lawful basis for each purpose: The legal basis should be stated for each distinct processing activity, not as a single catch-all.
• Recipients or categories of recipients: Who receives the data. This includes sub-processors such as hosting providers, payment processors and any third-party integrations.
• International transfers: If data is transferred outside the UK, the notice must explain the safeguards in place.
• Retention periods: How long data will be kept, or the criteria used to determine retention. "As long as necessary" is insufficient without further explanation.
• User rights: A clear explanation of the rights available under UK GDPR, including how to exercise them.
• Right to complain to the ICO: Users must be informed of their right to lodge a complaint with the supervisory authority.
• Whether providing personal data is a statutory or contractual requirement: And the consequences of not providing it.
• Automated decision-making, including profiling: If the application makes decisions about users based solely on automated processing, this must be disclosed along with meaningful information about the logic involved.

A practical problem with privacy notices in web applications is that they become outdated as features are added. Each new integration, data field or processing activity should trigger a review of the notice. Building a habit of updating the privacy notice as part of the release process prevents the notice from drifting out of sync with the actual system.

Data processing agreements for SaaS and web applications

A Data Processing Agreement is a contract between a data controller and a data processor that sets out the terms under which the processor handles personal data on behalf of the controller. Under UK GDPR, a DPA is a legal requirement — processing without one is a compliance failure regardless of how well the software itself functions.

When commissioning a web application or subscribing to a SaaS product, the DPA needs to address several specific areas:

• Subject matter and duration: What data is being processed, for what purposes, and for how long.
• Nature and purpose of the processing: A clear description that ties back to the controller's documented processing activities.
• Type of personal data: Categories of data subjects and the specific data items involved.
• Obligations and rights of the controller: The controller must instruct the processor in writing, and the processor must not process data outside those instructions.
• Confidentiality: Personnel processing the data must be subject to confidentiality obligations.
• Security measures: The processor must implement appropriate technical and organisational measures. The DPA should reference specific measures or a security annex, not rely on vague assurances.
• Sub-processor arrangements: If the processor uses sub-processors — hosting providers, email services, analytics platforms — the DPA must address how these are approved and what happens if a new sub-processor is introduced. Many SaaS products update their sub-processor list regularly, and the DPA should specify how the controller is notified.
• Assistance with subject rights: The processor must assist the controller in responding to data subject requests, which has practical implications for the application's data export and deletion capabilities.
• Breach notification: The processor must notify the controller without undue delay after becoming aware of a personal data breach. The DPA should define what "undue delay" means in practice and what information the notification will include.
• Data return and deletion on termination: At the end of the contract, the processor must return or delete all personal data and certify that this has been done. This has direct implications for data migration planning and exit strategies.
• Audit rights: The controller has the right to audit the processor's compliance. In practice, this is often satisfied by the processor providing evidence of certifications, but the DPA should specify the mechanism.

A common mistake is accepting a supplier's standard DPA without checking whether it aligns with the controller's own data mapping and processing records. If the DPA describes processing activities that do not match what the application actually does, or omits sub-processors that are in use, the document provides false comfort rather than genuine compliance.

For businesses building custom web applications, the DPA should be negotiated as part of the contract, not treated as an afterthought to be signed at launch. For SaaS products, the DPA is usually a separate document from the main subscription terms and should be reviewed before personal data is entered into the system.

Checks before relying on the system

• Document the precise processing scenario and who is authorised to approve exceptions.
• Confirm the organisation’s role for each processing activity rather than labelling every supplier a processor.
• Record the purpose, lawful basis, data categories, recipients, retention rule and international-transfer position.
• Check the Data (Use and Access) Act 2025 changes and the latest ICO guidance immediately before publication or implementation.

Primary guidance checked for this edition

Sources for “Compliance and Regulation” were checked on 22 July 2026. Recheck the applicable rules, product documentation and contractual terms before implementation because these can change after the review date.

• ICO: Data (Use and Access) Act 2025
• ICO: UK GDPR guidance and resources
• ICO: Storage and access technologies guidance