ISO 27001 certification readiness. Technical controls and evidence, ready for the auditor.
We help you reach the audit with cloud, server, repository and code controls working, plus dated before-and-after evidence. Certification is granted by an accredited body, not by WITS.
Mostly companies that sell software or cloud services, or process other companies' data, and get the question in a contract, a tender or a security questionnaire. Certification is voluntary: what makes it urgent is usually a large customer asking for it by a date. To understand the standard first, read what ISO 27001 is and what it's for.
SaaS and platforms
Enterprise customers ask for ISO 27001, or an equivalent questionnaire, before they sign.
Agencies and software studios
You run the cloud or code for several clients and need to show how you protect them.
Companies handling third-party data
Payroll, health, payments or personal data: the standard structures how you manage that risk.
What does the ISO 27001 certification process look like?
ISO doesn't certify anyone, as its certification page explains. The certificate comes from an external certification body, ideally an accredited one. Those bodies work to the requirements of ISO/IEC 17021-1 for auditing management systems. The typical path:
You implement the ISMS: scope, risk assessment and treatment, Statement of Applicability and the Annex A controls you chose to apply.
You run the internal audit and management review required by clauses 9.2 and 9.3 of ISO/IEC 27001:2022.
Stage 1: the body reviews your documentation and whether you're ready for the next stage.
Stage 2: the auditor verifies, with evidence, that the controls work.
If no major nonconformities remain open, the body issues the certificate. A three-year cycle with annual surveillance audits and a recertification at the end is the norm.
What does WITS do to prepare you for certification?
We focus on the technical side of Annex A, where companies get stuck most: proving a control exists and works. «We use MFA» isn't evidence; a report listing every user with their second factor is. It's Security OS's work (assessment, remediation and monitoring) applied to the controls your auditor will check.
The readiness path, in six phases
01/ 06 · Read-only assessment
01
Read-only assessment
We connect cloud, repositories and servers with permissions that can't change anything, and record your baseline.
02
Gap analysis
We compare findings against the technical Annex A controls you declared applicable and prioritize by risk.
03
Fixes with your approval
Every change comes with what changes, why and how to roll it back. Nothing is applied without your approval.
04
Before-and-after evidence
Two runs of the same audit engine, control by control, dated and ready for your consultant and auditor.
05
Audit rehearsal
We build the evidence list per control and rehearse the technical questions. An objective person runs the internal audit, as clause 9.2 requires.
06
Monitoring between audits
The same audit runs every month so controls don't drift before the annual surveillance audit.
Annex A control
What we review and fix
Evidence you keep
5.15 to 5.18 Access control, identity and access rights
Users, roles and keys in the cloud and GitHub; access held by former staff and vendors
Dated access inventory, before and after
5.23 Information security for use of cloud services
Account configuration: root, regions, logging, detection and cost alerts
Account baseline and differences between runs
8.2 Privileged access rights and 8.5 Secure authentication
Admins, MFA, unrotated keys, SSH access
MFA status per user and status of every key
8.8 Management of technical vulnerabilities
OS, PHP and dependency versions; published flaws that affect you
Prioritized findings with fix and close date
8.9 Configuration management
Cloud and server baseline, and drift from it
Baseline and differences between runs
8.13 Information backup
Database and storage backups, copies protected from deletion
Backup configuration and restore test
8.15 Logging and 8.16 Monitoring activities
Activity logging, detection alerts and who receives them
Logging configuration and active alerts
8.20 Networks security and 8.24 Use of cryptography
Open ports, firewall, TLS, disk and database encryption
Network rules and encryption status per resource
8.25 and 8.28 Secure development and secure coding
Code review (SQL injection, XSS, secrets, dependencies) and branch protection
Findings with file and line, and their fix
The auditor decides what evidence to accept; our job is to make sure yours is complete and dated. If your system runs on AWS, the AWS security audit guide details the account-level controls.
What falls outside our work?
Certification itself: the certification body you choose issues it.
Writing your whole ISMS. Policies, risk assessment and the Statement of Applicability belong to your company or consultant; if you already work with one, we coordinate.
People and physical controls (Annex A themes 6 and 7): hiring, awareness, offices and equipment.
Pentesting. We aren't a pentest firm: we prepare the system before the test and fix what it finds. More in pentest vs. security audit.
Legal advice.
For a first data point today, the free check reviews what your site shows the internet, and this week's alerts tell you what to patch before the audit.
We start with a read-only assessment. Tell us your scope and audit date.
No. An external certification body issues it, ideally an accredited one; ISO doesn't certify either. We prepare the technical controls and the evidence for your audit.
Do you guarantee I'll pass the audit?
No. The decision belongs to the certification body. What we deliver is complete, dated technical evidence with its before and after, so the auditor can verify each control.
How long does readiness take?
It depends on scope and on how many findings come up. The read-only assessment gives you a prioritized list you can use to plan dates with your certification body.
Do I need an ISMS consultant as well as WITS?
If nobody at your company knows the standard, it usually helps. The consultant handles risk, policies and the Statement of Applicability; we handle the technical side of cloud, servers, repositories and code, in coordination.
Which version of the standard applies?
ISO/IEC 27001:2022, with Amendment 1 from 2024. Its Annex A has 93 controls in four themes: organizational, people, physical and technological.
Does it work if my system isn't on AWS?
Yes. We review Linux servers, GitHub repositories and code wherever they run. If you use AWS, we also review the account in depth.
Review and drafting of legal documents is done with the support of legal specialists. WITS identifies needs and risks but does not provide legal services.
