What a Supplier's ISO 27001 Means for the Client

What a Supplier's ISO 27001 Means for the Client#

ISO 27001 is an international standard for information security management systems. When it is embedded in a supplier's delivery structure, it means risk assessment, access control, incident handling and change management are documented and repeatable, not dependent on one person. In practice this means a client can ask a supplier to demonstrate how data access, passwords, source code and production environments are handled, and that these rules hold regardless of which team member works on the project.

The standard alone does not prove a given project is secure – it shows a system exists that treats security systematically. For a client connecting ERP, CRM, document systems and reporting to a new solution, this matters because risk is not confined to the new application but extends to every system it exchanges data with. A systematic approach means the supplier assesses, before any integration, what data moves, who can access it, and how that access is monitored through the whole development cycle.

Within Epix and its specialist partner network, ISO 9001, ISO 20000/20001, ISO 27001 and ISO 27701 are established as part of the delivery structure. Project teams assembled for a given engagement operate within these frameworks whether the work is building an information system, integrating APIs, or providing post-launch support. For a client, the difference between a supplier handling security ad hoc and one operating inside a certified delivery structure becomes most visible during an incident, an audit, or a change of team member.

Why It Matters for Projects Connecting Multiple Systems#

Projects that connect ERP, CRM, production systems and reporting expand the scope of data a supplier can access beyond a single application. Every API integration is a new point where data moves between systems, and every such point is also a place where access needs to be controlled, logged and, where necessary, restricted. When a supplier operates within a structured security practice, it means the data being transferred, who accesses it, and how that access is documented for a future audit are all defined before the integration is built.

For an IT lead or director, this reduces uncertainty about who to trust with access to production systems. When a project is run by a project manager with clearly assigned team responsibilities, deadlines and a reporting method, it is clear who is accountable for each part of an integration and how changes are approved before reaching production. This matters especially for projects that connect existing systems, since an error in one integration can affect several departments at once.

Separating development, test and production environments follows the same logic. Real personal data is not used in the test environment, reducing the risk that sensitive client data ends up outside a controlled environment during development or testing. Changes go through review and testing before release to production, giving the client the ability to track changes and request additional verification before anything goes live.

What ISO 27001 Actually Covers at a Supplier#

ISO 27001 focuses on the information security management system as a whole, not on a single technology. The standard sets out how risks are assessed, how access is granted and revoked, how incidents are handled, and how documentation is maintained over time. For a client, it's important to understand this is not a technical report about one application, but a framework within which the supplier runs every project it takes on.

For a client managing ERP, CRM or document systems, this means the supplier can be asked concrete questions: how risks are assessed before a project starts, how access to passwords and production environments is managed, how an incident is handled if one occurs, and how documentation and access are handed over at project close or a change of supplier.

Within Epix and its specialist partner network, we can assemble a team with competencies across several security areas for demanding projects:

The scope a given project actually needs depends on whether it involves the public sector, a regulated industry, or an internal solution with no particular compliance requirements. Not every project needs the same set of security competencies – what matters is defining that scope at the start, not only once a question or incident arises.

• security architecture and infrastructure hardening
• penetration testing and vulnerability management
• identity and access management (IAM)
• incident response and digital forensics
• cloud security and DevSecOps
• compliance with GDPR and regulated-system requirements

How to Verify a Supplier Actually Meets the Requirements#

A certificate or a mention of a standard is not enough on its own – the client needs to know what it means in practice for their project. It's worth requiring concrete answers, before signing a contract, on how the supplier handles access, passwords, source code and data, and how these practices differ between development, test and production environments.

Questions worth asking a supplier before signing a contract:

The answers to these questions reveal more about a supplier's actual security practice than the name of a standard alone. At Epix and its partner network, source code and data belong to the client, while documentation, access and passwords are part of the handover at project close or at each project stage.

It's also worth checking how a supplier handles taking over an existing or unfinished system. For projects where the client already runs a working ERP, CRM or document system, an analysis of the existing source code, architecture, infrastructure and data is often needed before further development or new integrations can be planned.

• Who on the team has access to production data, and how is that access granted and revoked?
• How are passwords and access handled at project close or when a team member changes?
• Is real personal client data used in the test environment?
• How does the supplier document changes before they go to production?
• Who owns the source code and data after the project ends?
• How is post-launch support organized, and what are the issue-handling classes?

Environment Separation and Change Handling#

Separating development, test and production environments is one of the core elements of a systematic security practice. In practice, a change is first built and tested in an environment isolated from the data and operations the client relies on every day, and only then released to production.

Before a change reaches production, it's worth verifying it through test scenarios, manual and automated testing, and, where needed, acceptance testing against criteria agreed in advance. On more demanding projects, independent QA, separate from the development team, can be included, reducing the risk that the person who caused an error is also the one who is supposed to catch it.

For a client, this means not relying solely on trust in one developer, but on a process that catches errors before they affect system operation. This matters especially for projects connecting several departments, since an error in one part of a system can affect reporting, production or HR work at the same time.

Accountability, Data Ownership and Handover#

Security is closely tied to ownership. Source code and data belong to the client, while documentation, access and passwords are part of the handover. This means that at project close or a change of supplier, the client does not depend on the previous supplier's goodwill, but has agreed access to these elements.

For a director or IT lead, this matters because suppliers change over time while projects stay in use for years. A clearly agreed handover of documentation and access reduces the risk that the next development phase, or a change of supplier, ends up tied to the one person who originally built the project.

A project can be taken on in full or as a single work package, and an existing or unfinished system can also be taken over after a review of its source code, architecture, infrastructure and data. In both cases, documentation of access and data is the foundation that lets the next supplier actually assess the situation instead of starting the review from zero.

Post-Launch Support and Issue Handling#

Project security doesn't end when a system goes live. After launch, operational monitoring, bug fixing, technical and security updates, and further development can be taken over, meaning the system stays maintained after the original development phase is complete.

Issues and requests are then classified into severity classes, which tells the client how each case is prioritized for handling:

The specific response times for each class are agreed in the support contract and vary depending on how critical the system is for the client. It matters that these classes are defined in advance, not once an outage has already occurred, when every hour already counts.

• Class 1 – outage: the system or a key part is down, handled with the highest priority
• Class 2 – disruption: the system runs but a specific function doesn't, handled by agreed priority
• Class 3 – minor error: no impact on operations, scheduled into the next release
• Class 4 – request: a change or upgrade, scope is assessed and a timeline agreed

When a Supplier's Security Level Matters Most#

A supplier's level of security practice matters most for projects in the public sector and regulated industries, where documentation, traceability and compliance requirements are higher than for internal solutions without particular regulatory demands.

Industries where an experienced delivery structure and proven security practice matter most:

For projects in these industries, documentation, user training and a support SLA are often needed alongside development itself. In the public sector, for example, this includes information systems, portals, interactive solutions and documentation that must keep meeting the client's requirements throughout the system's use, not only at launch.

For a client in these industries, it's worth checking a supplier's security level before signing a contract, not once the project is underway. Questions about access, environment separation, handover and incident handling matter as much for these projects as the solution's functional requirements do.

• public sector
• banking and fintech
• insurance
• healthcare
• energy and critical infrastructure
• manufacturing and logistics

What It Means for the Client's Employees#

A supplier's security practice affects not only the system but also the employees who use it. Clearly defined access means each employee can only reach the data and functions they actually need for their work, reducing the risk of unintentional data exposure.

When a supplier plans documentation and training as part of a new system rollout, employees adapt to the change more easily while also understanding which data they may process and how. This matters especially for projects spanning several departments, where roles and access levels differ from one another.

For an HR lead or a department head, this means introducing a new system is not only a technical question but also a question of how everyday employee work changes and who is responsible for training and support in the period after launch.

How to Choose a Supplier for a High-Security Project#

When choosing a supplier for a project involving several systems and departments, it's worth checking whether the supplier has experience with similar projects, how they organize the project team, and how accountability for each part of the delivery is defined.

For larger projects, it helps when the supplier assigns a project manager, team responsibilities, deadlines and a communication and reporting method. This lets the client track progress during delivery and adjust scope where needed, rather than waiting until the end of the whole project to find out where something went off track.

Project cost depends on the scope of functionality, the number of systems that need connecting, security and compliance requirements, and the extent of post-launch support. Rather than a general price estimate, it makes sense to start with a short analysis that breaks the scope into work packages, so each one can be assessed and delivered separately.