Building software that handles personal information creates responsibilities beyond simply keeping a database secure.
Where LiteByte processes personal information on behalf of a client through public-cloud services, we use ISO/IEC 27018:2025 as a reference framework for the way that information is handled throughout the service lifecycle.
The standard is specifically concerned with protecting personally identifiable information — or PII — in public-cloud environments where the cloud service provider is acting as a processor on behalf of a customer.
For LiteByte, that can include systems we host and operate ourselves, infrastructure we configure within a client's cloud environment, integrations that move personal information between systems, and third-party cloud services that process information as part of the solution.
The exact responsibilities vary from project to project.
Our approach is therefore based on understanding what information is being processed, why it is needed, who is responsible for each part of the system, where the information can go, and what controls are required before processing begins.
Processing for the client's purpose
Why are we handling this information in the first place?
Where LiteByte acts as a processor, client-controlled personal information is processed for the agreed purpose and according to the client's instructions.
Having technical access to information does not give us permission to reuse it.
Client-controlled personal information is not repurposed for unrelated LiteByte activities, another client's project or LiteByte advertising and marketing.
Material changes to how or why personal information will be processed are reassessed rather than quietly becoming part of the system.
Clear responsibilities
Who is actually responsible for each part of the environment?
Cloud projects do not all have the same operating model.
LiteByte might create and operate the entire cloud environment.
We might configure services inside a client's existing Azure or AWS environment.
We might only operate an application that connects to a client-managed database.
Or we might have temporary access to production information during migration or support.
Before material processing begins, we establish where responsibility sits for areas such as:
- cloud infrastructure;
- production access;
- databases and storage;
- authentication and permissions;
- encryption;
- backups;
- logging and monitoring;
- retention and deletion;
- incident response; and
third-party services.
Where a control belongs to the client or cloud provider, we record that instead of pretending LiteByte operates something it does not.
Data minimisation
Are we processing more information than the system actually needs?
Personal information should not be collected or moved around simply because it might be useful later.
During design, we consider whether information can be avoided, reduced, masked, pseudonymised or processed without being permanently stored.
The same principle applies to application logs, temporary files, exports, development environments and third-party services.
The safest unnecessary copy of personal information is the one that was never created.
Cloud locations and transparency
Where can the information actually go?
For processing within LiteByte's responsibility, we maintain sufficient information to understand where personal information may be stored or processed.
Depending on the system, that can include:
- application hosting;
- databases;
- file storage;
- backups;
- logging and monitoring services; and
other cloud providers involved in the data flow.
Where processing crosses countries or regions, those arrangements are considered as part of the project's privacy and contractual requirements.
The goal is that the location of client data should be an architectural decision that can be explained, not something discovered after deployment.
Sub-processors and cloud suppliers
Who else receives or processes the client's information?
Modern cloud software depends on other services.
A system may use a cloud host, authentication service, email provider, monitoring platform, backup service, AI API or another specialist supplier.
Where LiteByte selects a provider that will process client-controlled personal information, we assess the provider before introducing it.
That includes considering:
- what information it receives;
- why the service is required;
- processing locations;
- contractual and data-processing terms;
- relevant security and privacy assurance;
- retention arrangements; and
client approval or notification requirements where applicable.
Approved providers are recorded and material changes are reviewed.
Using a well-known cloud service does not remove the need to understand what information is being sent to it.
Access to personal information
Who genuinely needs to see the data?
Access to client-controlled personal information is limited to people who require it for an authorised purpose.
Where LiteByte is responsible for the relevant access controls, this can include individual user accounts, multi-factor authentication, least-privilege permissions, restricted privileged access and periodic access review.
We also distinguish between access to the system and access to the information inside it.
A developer does not automatically need unrestricted production-data access simply because they are working on the application.
Development and testing
Do developers actually need real customer data?
Usually, no.
Our default is to use synthetic, anonymised, masked or appropriately pseudonymised information for development and testing.
Where genuine production PII is genuinely required, for example during a controlled data migration or investigation, its use is assessed, access is restricted and temporary copies are removed when they are no longer required.
Production data should not slowly accumulate across laptops, test databases and temporary exports simply because it is convenient.
Retention and deletion
How long should the information exist?
Personal information should have a reason for being retained.
For relevant systems, retention and deletion responsibilities are established for areas such as:
- production records;
- uploaded files;
- logs;
- temporary processing files;
- exports; and
backups.
Where practical, temporary information is removed automatically.
When LiteByte's processing role ends, the agreed process can include returning data to the client, transferring it to another provider, deleting LiteByte-controlled copies, revoking access and allowing protected backups to expire according to their documented retention arrangements.
Ending the contract should also end unnecessary processing.
Supporting individual rights
Can the client actually find, correct or delete someone's information?
Where LiteByte acts as a processor, the client normally remains responsible for responding to individuals exercising their data-protection rights.
Our responsibility is to make sure the systems and processes within our scope can provide the necessary technical assistance.
Depending on the system, that can include locating information, exporting it, correcting it, deleting it or restricting processing when instructed by the client.
Privacy rights should not depend on somebody manually searching through an undocumented database architecture.
Incidents and disclosures
What happens if personal information is exposed or somebody asks us to disclose it?
Suspected incidents involving client PII are escalated promptly.
That includes potential unauthorised access, accidental disclosure, lost information, compromised credentials, exposed systems or incidents reported by a supplier.
Where LiteByte acts as the processor, we provide the relevant client with information about a personal-data breach without undue delay and support the investigation and response.
Requests from law enforcement, regulators or other third parties for client-controlled information are also handled through an authorised process rather than being answered independently by an engineer.
Material incidents and disclosures are recorded so that what happened, how it was handled and what changed afterwards can be demonstrated.
Privacy throughout the project lifecycle
ISO 27018 alignment is not something we assess once at the end of a project.
For relevant engagements, our process starts during scoping.
Before development
We identify:
- the personal information involved;
- the purpose of processing;
- LiteByte and client responsibilities;
- data flows;
- cloud locations;
- sub-processors;
- access requirements;
- retention and deletion;
- security requirements; and
project-specific privacy risks.
Before production
We review whether the controls within LiteByte's responsibility were actually implemented.
That includes checking the final architecture, access, data flows, suppliers, processing locations, security controls, retention arrangements and operational readiness.
After launch
Where LiteByte continues to operate, administer or support the system, we retain an internal processing and assurance record covering material changes, access, suppliers, risks, incidents, restoration activity and eventual client offboarding.
This gives the project a traceable privacy lifecycle rather than a privacy document that becomes obsolete as soon as development starts.
What alignment means at LiteByte
ISO/IEC 27018 gives us a framework for protecting personal information when it is processed on behalf of clients through public-cloud services.
We turn that framework into practical decisions about purpose, responsibility, access, suppliers, location, retention, deletion and accountability.
The exact controls depend on the service.
If LiteByte operates the complete cloud environment, our responsibilities may be extensive.
If we are working inside infrastructure controlled by the client, responsibility may be shared.
If LiteByte does not process production personal information at all, many ISO 27018 requirements may sit outside the scope of that engagement.
What does not change is the principle:
We do not treat access to client data as permission to use it. We define why the information is being processed, understand where it can go, protect the parts we are responsible for, and retain evidence of how those responsibilities were handled.
About this alignment statement