Security should not begin with a penetration test the week before launch.
LiteByte uses ISO/IEC 27001:2022 as a reference framework for the way we manage information security across our organisation and software delivery.
ISO 27001 is built around an Information Security Management System (ISMS): a structured approach to understanding what information needs protecting, identifying security risks, implementing appropriate controls, retaining evidence and continually improving the security position over time.
For LiteByte, that creates a simple principle:
Understand what we are protecting, identify what could compromise it, apply proportionate controls and verify that those controls actually work.
Security starts with risk
Not every system needs exactly the same security controls.
Before development, we consider the information, systems, environments and services involved in the project and identify material information-security risks.
Those risks are considered through three fundamental security objectives:
Confidentiality - information is only available to authorised people and systems.
Integrity - information and systems cannot be changed improperly.
Availability - systems and information remain available when they are needed.
ISO 27001 requires a repeatable process for identifying security risks, assessing their likelihood and consequence, assigning ownership and prioritising them for treatment.
Rather than applying controls for the sake of a checklist, we use the risk to determine what protection is actually required.
Clear security responsibilities
Security responsibilities should not disappear between developer, client and cloud provider.
A LiteByte project may involve infrastructure we operate, infrastructure owned by the client, third-party cloud platforms and external software services.
We establish which party is responsible for areas such as:
- cloud infrastructure;
- identity and access;
- privileged administration;
- application security;
- databases;
- backups;
- monitoring;
- vulnerabilities;
- incident response; and
- ongoing operation.
Where the client controls something, we do not pretend that LiteByte controls it.
Where LiteByte is responsible, that responsibility is made explicit.
Access is based on need
Having access available is not the same as needing it.
We apply access controls according to the role, system and information involved.
That can include:
- individual identities;
- strong authentication;
- least privilege;
- restricted production access;
- controlled privileged accounts;
- appropriate removal of access; and
- review of access where ongoing responsibility remains.
ISO 27001's control framework specifically covers access control, identity management, authentication information, access rights and privileged access.
Our default principle is straightforward:
People and systems should have only the access required to perform their intended function.
Security is built into development
Security requirements belong in the design, not only in the final test.
For software projects, ISO 27001 includes controls covering:
- secure development lifecycle;
- application security requirements;
- secure architecture;
- secure coding;
- security testing;
- environment separation;
- change management;
- and protection of test information.
We therefore establish relevant security requirements during project scoping and carry them through architecture, implementation, testing and deployment.
The exact requirements depend on the system, but can include areas such as:
- authentication;
- authorisation;
- encryption;
- secrets management;
- input validation;
- secure configuration;
- dependency management;
- logging;
- monitoring;
- backup;
- recovery;
- and security testing.
Cloud does not remove responsibility
Using Azure, AWS or another established cloud platform does not automatically make the finished system secure.
Cloud security operates through shared responsibility.
The provider may secure the underlying infrastructure.
LiteByte or the client may still be responsible for:
- configuration;
- identities;
- permissions;
- networking;
- application security;
- data access;
- secrets;
- logging;
- monitoring;
- and operational processes.
ISO 27001 specifically includes security around the acquisition, use, management and exit from cloud services.
We make those boundaries clear rather than relying on the provider's security certifications as a substitute for securing the application itself.
Suppliers are part of the security boundary
Modern software is built on dependencies.
A secure application can still inherit risk through:
- cloud providers;
- software libraries;
- authentication providers;
- hosting platforms;
- monitoring services;
- AI providers;
- development tooling;
- and other third parties.
We consider the security relevance of those suppliers and dependencies rather than treating external services as inherently trusted.
ISO 27001 includes controls covering supplier relationships, contractual security requirements, ICT supply chains and changes in supplier services.
Vulnerabilities are managed, not merely discovered
Finding vulnerabilities is only useful if something happens afterwards.
We use vulnerability and dependency management appropriate to the system and the level of risk.
That can include:
- automated dependency scanning;
- static analysis;
- security testing;
- cloud/configuration review;
- penetration testing where warranted;
- remediation ownership;
- and verification that significant findings have actually been resolved.
ISO 27001 specifically requires technical vulnerabilities to be identified, exposure evaluated and appropriate action taken.
Secure configuration matters
Many security failures come from configuration rather than sophisticated attacks.
Examples include:
- publicly exposed storage;
- over-permissive identities;
- debug settings in production;
- insecure network rules;
- unnecessary services;
- or credentials stored in the wrong place.
ISO 27001 includes configuration management as a specific technological control.
For systems we operate, security-sensitive configuration should therefore be intentional, documented where appropriate and subject to controlled change.
Logging and monitoring
A security event is much harder to respond to if nobody can see that it happened.
Where appropriate, systems are designed to retain useful records of:
- authentication;
- privileged actions;
- system events;
- failures;
- security-relevant changes;
- and other operational activity.
But collecting logs alone is not enough.
Monitoring determines whether those records are actually being used to identify abnormal or suspicious behaviour.
ISO 27001 treats logging and monitoring as distinct security controls.
Backup and recovery
A backup only matters if it can be restored.
Where LiteByte is responsible for continuity or recovery, we establish appropriate requirements around:
- backup;
- retention;
- recovery;
- availability;
- and restore testing.
ISO 27001 specifically expects backup copies to be maintained and regularly tested according to the applicable requirements.
The objective is not simply to say that backups exist.
It is to understand what happens when something actually goes wrong.
Incidents are planned for
Good security assumes that incidents can still happen.
ISO 27001 includes controls for:
- preparing for security incidents;
- assessing security events;
- responding;
- learning from incidents;
- and preserving evidence.
Our approach is therefore not based on claiming that breaches or failures are impossible.
It is based on reducing their likelihood and impact, detecting relevant events and having a defined route for response and recovery.
Security includes availability and continuity
Security is not only about stopping unauthorised access.
A system that is unavailable when the client needs it has also failed an important security objective.
ISO 27001 therefore includes controls around maintaining information security during disruption and preparing ICT systems for business continuity.
Where relevant to the engagement, that means considering:
- provider outages;
- infrastructure failure;
- data loss;
- credential loss;
- dependency failures;
- and recovery requirements.
Evidence before release
Security should be demonstrable, not assumed.
Before production release, we verify that the security requirements established for the project have actually been implemented.
Depending on the system, evidence may include:
- security test results;
- access reviews;
- vulnerability scans;
- deployment configuration;
- backup or recovery tests;
- logging and monitoring;
- supplier records;
- risk treatment;
- and documented acceptance of any remaining security risk.
Where issues remain, they are recorded rather than disappearing into an informal conversation.
Security continues after launch
Systems, suppliers and threats change.
Security therefore needs to be reassessed when material changes occur.
Examples include:
- new infrastructure;
- new suppliers;
- new external integrations;
- new categories of sensitive information;
- changes to authentication;
- changes to privileged access;
- major architecture changes;
- or significant incidents.
ISO 27001 requires risk assessments to be repeated at planned intervals and when significant changes are proposed or occur.
A management system, not a stack of policies
ISO 27001 goes beyond engineering controls.
A functioning ISMS also requires organisational responsibilities, competence, awareness, objectives, documented information, monitoring, internal audit, management review and continual improvement.
That distinction matters.
A company does not have a mature security programme simply because it has written a password policy.
The policies, controls and processes need to operate in practice and produce evidence that they are effective.
What alignment means at LiteByte
LiteByte uses ISO/IEC 27001:2022 as the reference framework for its wider information-security management approach.
At project level, that means:
- understanding the security boundary;
- identifying the information and systems that need protecting;
- assessing confidentiality, integrity and availability risks;
- making security responsibilities explicit;
- translating risks into engineering controls;
- verifying those controls before release;
- and reassessing the security position as systems change.
At organisational level, those project controls sit within our wider security-management processes, including policies, risk management, supplier controls, security objectives, training, incident management, review and continual improvement.
Our ISO/IEC 27001 approach also works alongside the more specialised frameworks we use for software quality, cloud privacy and AI assurance, without duplicating the same controls across each framework.