Book a callBook a callSend your requestContact
Book a call

The standard

What does ISO/IEC 27001:2022 need from engineering?

ISO/IEC 27001:2022 specifies requirements for an information security management system: risk assessment and treatment, objectives, internal audit, management review and continual improvement. You compare the controls your risk treatment needs with Annex A and record the result in a Statement of Applicability (clause 6.1.3). ISO/IEC 27002:2022 lists 93 controls: 37 organizational, 8 people, 14 physical and 34 technological. Engineering owns most of the technological ones and part of the organizational ones.

The standard prescribes no fixed control list. Annex A is a reference, and controls can come from any source (clause 6.1.3, notes 1 and 3). The engineering you owe depends on the risks you treated and the exclusions you justified.

A certification audit looks at the whole management system, with controls as one part of it next to scope, risk assessment, internal audit and management review (clauses 4 to 10).

Certification

Who certifies ISO/IEC 27001?

An external certification body, not ISO and not an engineering vendor. ISO states that it does not perform certification or issue certificates. Accreditation of the certification body is not compulsory, but it gives independent confirmation of its competence, and an accredited certificate can be verified in the IAF CertSearch database. When a certificate is cited it should name the edition: certified to ISO/IEC 27001:2022.

What we do not claim

What do we not claim?

We hold no ISO/IEC 27001 certificate and claim none for any client. We are not a certification body, and we have no published ISO 27001 implementation case.

  • Management system governance stays with your management or your ISO consultant: scope, risk assessment, Statement of Applicability, internal audit and management review. We build what those documents commit you to. We do not write or approve them.
  • The cases linked below show the same technological controls in other work. They are not an ISO 27001 implementation.
  • We guarantee no certification outcome: the audit finding belongs to the certification body.
  • We claim no work under ISO/IEC 27701 (privacy), no work under ISO/IEC 42001 (AI), and no partnership with any compliance-automation (GRC) platform.

When we are your supplier

Which controls apply to us as your outsourced engineers?

When you outsource development or run operations through contractors, ISO/IEC 27002:2022 controls on suppliers become yours to evidence: 5.19 information security in supplier relationships, 5.20 supplier agreements, 5.21 the ICT supply chain, 5.22 monitoring and review of supplier services, 5.23 use of cloud services and 8.30 outsourced development.

A reviewer is likely to ask for the supplier agreement, how the supplier's engineers are vetted, and how their access is controlled and removed. Security and procurement answers each from what is true today, and it lists what we do not claim.

The controls

Which technological controls does the engineering team run?

Six groups of Annex A controls land on engineering: access, secure development and change, logging and monitoring, backup and continuity, vulnerabilities and configuration, and cryptography with network and data protection. For each: the control numbers, the engineering work, and where we have done it in a published case.

Access and authentication

What it asks of engineeringWho has access to systems and source code, how do they authenticate, and who reviews their rights?

Controls 5.15 to 5.18 cover access control, identity management, authentication information and access rights. Controls 8.2 to 8.5 cover privileged access rights, information access restriction, access to source code and secure authentication. The engineering: identities on your SSO, MFA, least privilege, repository permissions as code, secrets in a managed store and workload identity for services. The periodic review of rights is performed by your team.

Where we have done it

No fixed package covers access control on its own. We scope it in Discovery or with engineers by the hour.

Secure development and change

What it asks of engineeringHow is security built into development, and how does a change get approved, tested and released?

Controls 8.25 secure development life cycle, 8.26 application security requirements, 8.27 secure system architecture, 8.28 secure coding, 8.29 security testing, 8.31 separation of development, test and production, and 8.32 change management. The engineering: a pipeline whose gates can stop a release, tests on every change, separate environments, and releases that are traceable and have a rehearsed way back.

Where we have done it

Delivered by

Logging and monitoring

What it asks of engineeringWhat do you log, who watches it, and do the alerts fire when they should?

Controls 8.15 logging, 8.16 monitoring activities and 8.17 clock synchronization. The engineering: metrics, logs and traces wired with synchronized clocks, alerts tested until they fire, and a runbook. We work in your business hours and leave alerts and runbooks so that your own on-call can resolve incidents.

Where we have done it

Delivered by

Backup, redundancy and continuity

What it asks of engineeringAre there backups, is there redundancy, and has anyone shown that a restore works?

Controls 8.13 information backup, 8.14 redundancy of information processing facilities and 5.30 ICT readiness for business continuity. The engineering: encrypted, scheduled backups, restore drills and a rehearsed rollback, so recovery is shown rather than assumed.

Where we have done it

No fixed package covers backups and recovery on their own. We scope them in Discovery or with engineers by the hour.

Vulnerabilities, malware and configuration

What it asks of engineeringHow do you find known vulnerabilities before code ships, and how do you keep configuration under control?

Controls 8.7 protection against malware, 8.8 management of technical vulnerabilities, 8.9 configuration management and 5.7 threat intelligence. The engineering: scans in the pipeline on every change with suppressions that expire, and infrastructure defined as code, applied through a pipeline, where a plan that would destroy a resource stops first.

Where we have done it

Delivered by

Cryptography, network and data protection

What it asks of engineeringIs data encrypted in transit and at rest, how are networks segregated, and how is test data handled?

Controls 8.24 use of cryptography, 8.20 networks security, 8.22 segregation of networks, 8.10 information deletion, 8.11 data masking, 8.12 data leakage prevention and 8.33 test information. The engineering: TLS in transit, managed keys and encryption at rest, private network paths to data stores, a web application firewall at the edge, and masked data outside production.

Where we have done it

No fixed package covers cryptography and data protection on their own. We scope them in Discovery or with engineers by the hour.

How we deliver

How do our packages and engineers deliver it?

Start with a fixed-price package, or hire engineers by the hour. The CI/CD & IaC package builds the pipeline and the infrastructure as code. SRE / Observability Foundations wires the monitoring. QA Automation Foundations puts tests in your CI. Discovery turns your Statement of Applicability, or your certification auditor's findings, into a roadmap with a backlog.

Pipeline and infrastructure as code

A 2-week build or re-architecture of your CI/CD pipelines and your infrastructure as code. The gates that go into the pipeline, such as a vulnerability scan, are agreed in the SOW.

Delivered by

Logging and monitoring

Metrics, logs and traces wired, 3 SLOs defined, alerts tested until they fire, and a runbook.

Delivered by

Tests on every change

A Playwright suite for your 5 critical flows, running in your CI, with accessibility checks.

Delivered by

From the requirement list to a backlog

Discovery understands your product and its configuration end to end and delivers a roadmap with a backlog, roles, critical changes and needs. Bring your Statement of Applicability or the auditor's findings, and we turn them into engineering work.

Delivered by

Engineers by the hour

For the work that continues after a package: Senior USD 45–⁠50 an hour, Lead or Architect USD 55–⁠60, with a 6-month minimum, billed per hour worked. You interview the engineer who will do the work.

Sources

Which texts did we read?

Primary texts, read on 2026-10-09. We did not read the paid body of Annex A or the control guidance of ISO/IEC 27002. The control numbers and names below come from the table of contents of ISO/IEC 27002:2022, and the engineering is ours.

  • ISO/IEC 27001:2022, the publisher's preview extract: table of contents, introduction and clauses 4 to 6, including 6.1.3.
  • ISO/IEC 27002:2022, the publisher's preview extract: table of contents with controls 5.1 to 8.34.
  • iso.org: the ISO/IEC 27001 page, and the certification page that states ISO does not perform certification.

Frequently asked questions

Is Clouditive ISO 27001 certified?

No. We hold no ISO/IEC 27001 certificate and claim none for any client. This site publishes no ISO certificate, no third-party audit report and no insurance statement.

Can Clouditive certify us or run the audit?

No. Only an external certification body can certify an organization, and ISO itself does not perform certification. We build the technological controls; the certification body audits the whole management system.

Do we have to implement all 93 controls?

No. You select the controls your risk treatment needs and record them in a Statement of Applicability, with a justification for each Annex A control you exclude (clause 6.1.3). The engineering follows that selection.

We outsource development to you. What changes for our certification?

The supplier controls become yours to evidence: supplier relationships, agreements, the ICT supply chain, monitoring of supplier services and outsourced development. Our contracting, vetting and access terms are written down for that review.

Do you have an ISO 27001 implementation case?

No. We have no published ISO/IEC 27001 implementation. The cases linked on this page show the same technological controls in fintech analytics, govtech, AI, gaming and transportation work.

How long does it take to get ready?

It depends on what you already have, and we give no guarantee about a certification audit. A 2-week package builds one area, such as the CI/CD pipeline and infrastructure as code, and Discovery, 1 to 4 weeks, turns the rest into a roadmap.

How does this relate to SOC 2 and the other frameworks?

The engineering overlaps a lot: gated releases, access you can prove, tested alerts and drilled recovery serve several frameworks at once. The compliance engineering page shows which clause of each framework asks for which control.

How do your engineers get access to our systems?

Through your own accounts and identities, with your SSO, your MFA and least-privilege access, revoked when the engagement ends. Every engineer passes a background check before assignment.

Who does the work?

Mat Caniglia leads every project end to end, and the engineers are in LATAM and share your working day. We present candidates within 1 week, and you interview the engineer who will do the work.

Tell us your case.

We reply to every request within 1 business day. We sign an NDA before the call if you ask.

Send your requestBook a 30-min call