ISO/IEC 27001 helps an organisation manage information-security risk through an information security management system, or ISMS. For a software buyer, the practical question is which requirements apply to the engagement and what evidence demonstrates that they are operating.
Certification and alignment are different claims. A supplier describing selected practices as aligned to the standard has not thereby demonstrated independent certification or conformity across an entire ISMS.
Understand the standard and certification scope
ISO/IEC 27001:2022 defines ISMS requirements; the standard record also lists its 2024 amendment. ISO/IEC 27002 provides control implementation guidance. An ISMS includes governance, risk assessment and treatment, operation, evaluation and improvement, rather than only technical safeguards. ISO standard record.
When a contract requires certification, request the current certificate, scope, issuing body and validity information. Check whether the scope covers the supplier service you are buying. If independent accredited certification is required, an internal alignment statement is not a substitute.
This article does not present Nodesify as ISO/IEC 27001 certified. Any procurement decision requiring certification should be based on current documentary evidence supplied for that decision.
Use Annex A as a reference, not a universal installation list
The 2022 Annex A catalogue contains 93 controls: 37 organisational, eight people, 14 physical and 34 technological. Organisational controls form the largest group, not a majority of the catalogue.
Control selection follows risk treatment and the Statement of Applicability. Implementing a few technical controls does not complete the ISMS or turn the remaining work into paperwork.
| Control area | Reference | Example delivery evidence |
|---|---|---|
| Access and identity | A.5.15–A.5.18 | Access model, named accounts and review records |
| Supplier security | A.5.19–A.5.23 | Supplier assessment and agreed responsibilities |
| Incident management | A.5.24–A.5.28 | Response process, exercises and incident records |
| Logging and monitoring | A.8.15–A.8.16 | Relevant events, protected records and alert ownership |
| Cryptography | A.8.24 | Policy, key responsibilities and implementation evidence |
| Secure development | A.8.25–A.8.28 | Lifecycle, requirements, architecture and coding practices |
| Environment separation | A.8.31 | Documented development, test and production boundaries |
Use an authorised copy of the applicable standard when preparing a formal control mapping. The examples above are prompts for discussion, not an exhaustive compliance checklist.
Relate the controls to Malaysian requirements
Malaysia’s PDPA and sector-specific technology requirements may overlap with ISMS controls, but satisfying one framework does not automatically satisfy another. A bank or government customer may require certification or specified evidence through its procurement terms. Check the actual clause rather than assuming all Malaysian tenders use the same rule.
For the privacy scope, see our PDPA website guide and cloud-vendor obligations guide. Keep statutory duties, customer requirements and voluntary improvements distinct in the delivery plan.
Ask for evidence relevant to your system
An access policy is useful only if accounts, privileges and reviews follow it. A logging policy needs a defined event set, retention, restricted access and an owner who acts on alerts. A supplier assessment needs follow-up when the supplier or data flow changes.
Request evidence appropriate to confidentiality constraints: a scoped control summary, assurance reports, review records or agreed demonstrations. Do not assume that a certificate proves every individual configuration is correct, or that a supplier without certification has no security controls.
Cryptography requirements should account for threat model, interoperability, key management and applicable agreements. The standard is not a universal mandate to install one WAF brand or use one cipher everywhere.
Plan the effort around gaps
Certification time and cost depend on scope, organisational maturity, operating evidence and the certification process. Avoid promising a fixed completion period or assuming that alignment always clears procurement. Start with the contract requirement and a gap assessment, then assign owners and measurable completion criteria.
Assign evidence to the party that can produce it
For an illustrative procurement request, the buyer’s governance owner defines the required assurance and acceptable scope; the application supplier supplies access, change and recovery evidence for its delivery; the cloud provider supplies applicable provider documentation. None of those records automatically proves the other party’s controls. Keep evidence owner, scope, issue date, expiry/review date and unresolved questions together.
If a tender explicitly requires certification, verify the certificate, covered organisation/services and procurement acceptance with the buyer. If the requirement is selected controls or alignment, document which controls apply, implementation evidence and gaps. Do not relabel alignment as certification. Legal, contractual and certification interpretations belong with the responsible specialists.
Frequently Asked Questions
Can a provider’s certificate cover our whole application?
Do not assume that. Map the certificate’s scope to the services used and identify the responsibilities retained by the business and implementation team.
What should we ask an implementation supplier to deliver?
Specify the required access records, change approvals, restore evidence and operating handover for the agreed scope. Use the delivery evidence guide; request an architecture review when existing-system evidence is incomplete.
A buyer can request a bounded evidence matrix: the control or contractual requirement, its owner, the system in scope, the artefact that demonstrates operation and the date of the last review. For example, a backup policy is different from a successful restore record. This is a procurement example, not an ISO audit checklist or a claim that Nodesify is certified. The customer should confirm the exact standard edition and tender wording before treating a control number as mandatory.
Is alignment the same as certification?
No. Alignment describes claimed practices; certification requires the relevant independent assessment. Verify scope and status rather than relying on the wording of a marketing page.
Does a secure software build complete the ISMS?
No. Management responsibilities, risk treatment, operation, internal audit, review and improvement remain necessary parts of the system.
For a technical assessment, use our architecture audit service and identify the customer clauses and evidence you need before work starts.
