All compliance frameworks
Privacy management

ISO/IEC 27701

Privacy Information Management Extension

Privacy, managed throughout the data lifecycle.

Privacy management practices aligned with ISO/IEC 27701:2025

Aligned framework
ISO/IEC 27701 badge

Applied in proportion to the project scope, information and risk.

On this page
  1. Clear roles and responsibilities
  2. Purpose before processing
  3. Privacy risk, not only security risk
  4. Privacy impact before major change
  5. Privacy by design and by default
  6. Data minimisation
  7. Retention and deletion
  8. Individual rights need technical support
  9. Transparency about processing
  10. Automated decisions need additional attention
  11. Third parties are visible
  12. International transfers are considered
  13. Privacy-conscious development and testing
  14. Privacy continues after deployment
  15. A privacy management system, not just a privacy notice
  16. What alignment means at LiteByte

Protecting personal information is about more than keeping a database secure.

LiteByte uses ISO/IEC 27701:2025 as a reference framework for the way we manage privacy around personally identifiable information, PII, across software delivery and ongoing services.

The standard establishes a Privacy Information Management System (PIMS) for organisations acting as PII controllers, PII processors, or both. It covers the management of privacy risk, responsibilities, processing purposes, individual rights, privacy by design, third parties, transfers, monitoring and continual improvement.

For LiteByte, that creates a simple principle:

Know why personal information is being processed, use only what is necessary, make responsibilities clear and design the system so privacy obligations can actually be fulfilled.

Clear roles and responsibilities

Privacy responsibility depends on what each organisation is actually doing with the information.

A client may determine why personal information is processed.

LiteByte may process that information on the client's documented instructions.

In other circumstances, an organisation may act as a controller, processor or share controller responsibilities for particular processing activities.

We identify those roles during project scoping rather than assuming that every software supplier has the same privacy position.

Where multiple organisations are involved, responsibilities around PII processing, protection and security should be made explicit.

Purpose before processing

Personal information should have a reason for being there.

Before processing PII, we establish the intended purpose.

That means understanding:

  • what information is required;
  • why it is needed;
  • who determines that purpose;
  • how it will be used;
  • and whether later changes would introduce a different purpose.

For controllers, ISO 27701 expects the purposes of PII processing to be identified and documented.

For processors, the information should be processed according to the customer's documented purposes and instructions.

This helps prevent personal information collected for one legitimate reason quietly becoming used for another without proper assessment.

Privacy risk, not only security risk

Information can be secure and still be processed badly.

Encryption and access control matter, but privacy goes further.

A system can be technically secure while still:

  • collecting excessive information;
  • retaining it for too long;
  • using it for an unexpected purpose;
  • making inappropriate automated decisions;
  • or preventing individuals from exercising their rights.

ISO 27701 therefore includes a dedicated privacy risk assessment and treatment process alongside wider information-security controls.

For relevant projects, we consider both what could happen to the information and what the processing itself could mean for the people the information relates to.

Privacy impact before major change

New processing can create new privacy consequences.

When a project introduces new PII processing or materially changes existing processing, we consider whether a Privacy Impact Assessment is required.

Factors can include:

  • the amount of information involved;
  • sensitive categories of PII;
  • children or vulnerable people;
  • new technologies;
  • automated decision-making;
  • profiling;
  • systematic monitoring; and
  • other processing capable of significantly affecting individuals.

ISO 27701 specifically expects organisations to assess the need for a privacy impact assessment when new or changed PII processing is planned.

Privacy by design and by default

Privacy requirements should influence the architecture before development is finished.

We consider privacy during system design rather than treating it as a notice added at launch.

Depending on the project, that can mean designing for:

  • limited collection;
  • limited processing;
  • appropriate defaults;
  • de-identification;
  • controlled disclosure;
  • retention;
  • deletion;
  • access and correction;
  • consent changes;
  • secure transmission; and
  • appropriate handling throughout the PII lifecycle.

ISO 27701 expressly connects PII processing with privacy by design and privacy by default, including secure development and architecture requirements around personal information.

Data minimisation

Just because information can be collected does not mean it should be.

We challenge the amount of personal information required for a system.

The objective is to collect and process information that is relevant, proportionate and necessary for the identified purpose, rather than collecting additional fields simply because they may be useful later.

Where identifiable information is unnecessary, de-identification or other minimisation techniques can also be considered.

The engineering question is straightforward:

Why does the system need this information?

Retention and deletion

Personal information should not remain indefinitely by default.

Where relevant, projects define how long PII needs to be retained and what should happen when that period ends.

That includes considering more than the primary database.

PII can also exist in:

  • temporary files;
  • exports;
  • logs;
  • backups;
  • processing artefacts;
  • and third-party systems.

ISO 27701 states that PII should not be retained longer than necessary for the purposes for which it is processed and specifically addresses temporary files and disposal.

Where LiteByte processes information for a customer, we also consider how it can be securely returned, transferred or disposed of when processing ends.

Individual rights need technical support

Privacy rights only work if the system can support them.

Depending on the applicable legal requirements and the roles involved, people may have rights or requests concerning:

  • access;
  • correction;
  • erasure;
  • objection;
  • consent withdrawal;
  • copies of their information;
  • or other restrictions on processing.

ISO 27701 includes controls around supporting these types of requests and providing mechanisms for individuals to interact with the processing of their PII.

Where LiteByte is acting as a processor, the client may remain responsible for deciding how a request should legally be handled.

Our responsibility may instead be to make sure the system and service can technically support them.

Transparency about processing

People should be able to understand how their information is being used.

Depending on the processing and the organisation's role, relevant information may include:

  • the purpose of processing;
  • who is responsible;
  • the lawful basis;
  • where information came from;
  • who receives it;
  • where it may be transferred;
  • how long it is retained;
  • what rights are available;
  • and whether automated decision-making is involved.

ISO 27701 expects information provided to individuals to be clear, accessible and appropriate to the processing.

The objective is not simply to publish a long privacy notice.

The information presented to people should reflect how the system actually operates.

Automated decisions need additional attention

Using personal information to make decisions about people can materially increase privacy risk.

Where systems use automated processing to influence or make decisions about individuals, we identify the relevant privacy obligations and system requirements.

That can include questions around:

  • what information drives the decision;
  • how consequential the outcome is;
  • whether a human is involved;
  • what information the individual should receive;
  • and what mechanisms exist to challenge or review the result.

ISO 27701 specifically includes automated decision-making within its controller privacy controls.

Where AI is involved, these privacy considerations work alongside our wider AI risk and governance processes.

Third parties are visible

Personal information often travels through more organisations than the main application suggests.

A modern system may involve:

  • cloud hosting;
  • email providers;
  • monitoring services;
  • authentication platforms;
  • support systems;
  • AI providers;
  • and other subcontractors.

Where LiteByte processes PII on behalf of a customer, ISO 27701 expects appropriate transparency and contractual control around subcontractors used to process that information.

We therefore consider who receives client information rather than treating third-party infrastructure as invisible.

International transfers are considered

Where the data goes matters.

Cloud services can cause PII to be processed or transferred across jurisdictions.

Where relevant, we identify:

  • countries involved;
  • third-party recipients;
  • transfer arrangements;
  • and applicable client or legal requirements.

ISO 27701 expects organisations to document the basis for transfers between jurisdictions and the countries or international organisations to which PII may be transferred.

Privacy-conscious development and testing

Production personal data should not become convenient test material.

Where practical, we prefer false, synthetic or appropriately de-identified information for development and testing.

If real PII genuinely has to be used, it should receive protections appropriate to the production information and the associated risk.

ISO 27701 specifically addresses the selection and protection of test information and recommends synthetic or false PII where practical.

Privacy continues after deployment

Processing changes over time.

A system may introduce:

  • new categories of PII;
  • new purposes;
  • new suppliers;
  • new countries;
  • new user groups;
  • new automated decisions;
  • or new retention requirements.

Those changes can alter the privacy position even when the underlying application appears similar.

ISO 27701 requires privacy risk assessments at planned intervals and when significant changes are proposed or occur.

We therefore treat material privacy changes as reassessment triggers rather than assuming the original assessment remains valid forever.

A privacy management system, not just a privacy notice

ISO/IEC 27701:2025 is a management-system standard.

It goes beyond individual project controls and includes:

  • privacy responsibilities;
  • policies;
  • risk assessment;
  • objectives;
  • competence and awareness;
  • documented information;
  • operational controls;
  • monitoring;
  • internal audit;
  • management review;
  • and continual improvement.

That distinction matters.

A company does not have a mature privacy programme simply because it has a privacy policy on its website.

The controls need to operate in practice and produce evidence that privacy is being managed throughout the lifecycle.

What alignment means at LiteByte

LiteByte uses ISO/IEC 27701:2025 as a reference framework for the way we manage privacy around personally identifiable information.

At project level, that means:

  • understanding our privacy role;
  • defining why PII is being processed;
  • identifying privacy risks;
  • considering privacy impact before significant processing begins;
  • minimising unnecessary collection and use;
  • designing systems that can support relevant individual rights;
  • making third parties and transfers visible;
  • planning retention and deletion;
  • and reassessing when the processing changes.

These practices work alongside our wider information-security, cloud privacy, software-quality and AI assurance frameworks so that overlapping controls can share evidence rather than being duplicated.

Assurance, scoped to the engagement

Have a particular compliance requirement?

Tell us what you are building, the information involved and the assurance your stakeholders need.

Discuss your requirements