Supplier management policy

How we choose, contract and review the suppliers that handle our information or our customers’ information, including cloud services and outsourced development. It applies to everyone who buys or uses a service for a d-centralize company.

Annex A controls: 5.19, 5.20, 5.21, 5.22, 5.23, 8.30.

Suppliers and critical suppliers (5.19)

The supplier register in the ISMS registers lists every supplier that processes company or customer information: what it provides, which information it processes, its agreement and processing agreement, and whether it is critical. The office wiki lists the subscriptions of each company.
A supplier is critical when at least one of these applies:
- it hosts our production systems, customer data or backups;
- it processes personal data of our customers or their users on our behalf;
- its outage stops a customer-facing service or our ability to restore it, such as DNS, domain names or source code hosting.
We choose suppliers by the purchasing policy: open source with the option to self-host is preferred, and the service has an API so we can automate it and take our data out.
A new supplier or cloud service is a big change: before it is used, the Information Security Officer checks its security impact in the change issue (change management) and it is added to the register.
AI subscriptions are bought centrally (AI tools).

Security in supplier agreements (5.20)

Every supplier that processes personal data on our behalf has a processing agreement (GDPR article 28) that covers confidentiality, security measures, notification of breaches, sub-processors, the location of the data, and return or deletion of the data when the service ends. Transfers outside the EU/EEA are covered by the agreement.
For standard cloud services, the supplier’s terms and processing agreement are accepted at sign-up. The register entry links to the version we accepted.
A critical supplier shows that it manages information security: an ISO/IEC 27001 certificate, a SOC 2 report or equivalent evidence.

ICT supply chain (5.21)

Software dependencies and container images come from maintained upstream projects and are pinned to versions (external dependencies, image tags). Updates and licence checks follow the secure development policy.
A critical supplier lists its sub-processors in its processing agreement. A change of sub-processor is reviewed as a supplier change (5.22).
We prefer services we can replace: open standards, data export and a self-hosting option (purchasing policy).

Monitoring and review of suppliers (5.22)

Every year the Information Security Officer reviews each critical supplier: certificate still valid, processing agreement in place, incidents and service quality of the past year, and changes to the service or its terms. The other suppliers are reviewed by sample. The result is recorded in the ISMS recurring tasks.
Monitoring checks the availability of the supplier services we depend on and alerts in Mattermost (operations security).
Office & HR reviews the supplier invoices with Management every month, so a new or unknown service shows up.
A change announced by a supplier, such as new terms, a new sub-processor, another data location or the end of a service, is assessed as a change (change management).

Cloud services (5.23)

Acquisition: as for any supplier (5.19, 5.20).
Use: we use company accounts, never personal ones. Sign in through SSO where the service supports it, otherwise with a unique password and 2FA. Shared credentials go in the Vaultwarden collection of the company that owns the account (collections).
Information sent to cloud AI services follows what not to paste into cloud AI.
Exit: data at a cloud supplier can be exported, and backups of critical systems are kept outside their hosting supplier (business continuity). When a cloud service ends, its data is moved or deleted and its accounts and credentials are removed (infrastructure teardown).

Outsourced development (8.30)

Freelancers and development companies that develop for us work under a contract that covers confidentiality, ownership of the code and the security requirements of this handbook.
They get their accounts through the normal onboarding, sign in with SSO and 2FA, and get access only to the projects they work on (access control).
Their changes go through the same merge request review as ours (secure development). Core team developers lead architectural choices, because they maintain the code afterwards (team).
Their access ends through the normal offboarding.

Responsibilities

The Information Security Officer owns this policy and the supplier register, checks new suppliers and runs the yearly supplier review.
Management approves and signs agreements with critical suppliers.
Infrastructure manages the hosting and infrastructure suppliers and monitors their availability.
Project leads request the suppliers their product needs, keep those register entries current and direct outsourced development for their product.
Office & HR keeps the subscription lists and checks the supplier invoices.

Review: yearly by the Information Security Officer.