A large customer sends a security questionnaire, a long list of questions about how you protect their data. Or a prospect asks whether you are ISO 27001 certified. The deal waits on the answer.
That is how ISO 27001 implementation for a business usually begins. It rarely starts as a security project. It starts as a sales problem, and is solved by changing a few day-to-day habits.
ISO 27001 is an international standard for information security management. It sets out what a business must have in place to manage risks to its information, and keep managing them. The current edition is ISO/IEC 27001:2022. Certification is optional; some businesses run the standard without certifying.
A software company we worked with decided it needed ISO 27001, mostly because larger prospects kept asking for it. They bought policy templates and filled in the blanks.
They had a thick binder that described a security programme nobody ran. The policies referred to roles, reviews and registers that did not exist. Risk had never been assessed properly, so the controls were a generic checklist. A control is the standard’s word for a safeguard you put in place.
We set the binder aside and started from how the company worked: what it builds, what data it holds, what would hurt most. From that we ran a risk assessment and chose each control because it answered a real risk.
Then we put each control into operation first, and documented it as it ran. We also set up the rhythm: internal checks, a way to handle what goes wrong, and a management review. That is where senior people look at how the programme runs. We sized each so the team could keep it going.
The company now runs a security programme that matches its paperwork, because the paperwork was written from the practice. We have written up how we made ISO 27001 a way of working for them.
The documents have to describe what your team does, because that is what the auditor tests. This was a software company, but the same habits apply in a plant or a warehouse.
Why a customer’s questionnaire is usually the real trigger
A logistics software provider we worked with kept stalling at the same point in every deal: the prospect’s security questionnaire. Each one asked for evidence of controls. The team ran most of them but had never written them down, and a few it did not have.
The founders filled in spreadsheets from memory while the deal slowed. A couple of deals went to competitors who could hand over a SOC 2 report, an independent assessor’s report on their controls. They asked us why every promising conversation went quiet once procurement got involved.
We started with an inventory of systems, data and access, which answered most of the questionnaire on its own. It also turned up access that should have ended long ago: ex-contractors who could still log in, and shared logins kept because they were convenient.
They now answer a questionnaire from a single, current account of what they run and how it is protected. We have written up how we closed the gaps before their customers’ security reviews.
A questionnaire asks what the standard asks: what do you run, who can reach it, and what happens when something breaks. A current record of those three answers most of it.
The five habits behind ISO 27001 compliance
For an operations business, that comes down to five habits. None starts with buying software. Each needs an owner and a routine: someone who already runs the systems, with one senior person reviewing the whole picture on a schedule. It does not need a security department.
- Know what you have. A current list of the systems you run, the data each holds, and who owns it. Note what would hurt most if each failed or leaked. That short list is the start of your risk assessment, and the reason each control exists.
- Know who can reach it. For each system, which people have access and why. Access is granted to a role, reviewed when someone changes job, and removed promptly when they leave. Shared logins go, so that every action can be traced to a named person.
- Know what your suppliers can reach. Every tool, agency and integration that connects to your systems or holds your data, and what each one could touch.
- Know what happens on a bad day. A short plan that says who decides and who calls whom. Backups you have restored in a test, so you know they work. A rehearsal, so the first time the plan is used is not a real incident.
- Keep the evidence as you go. The record of the last access review. The log of the restore test. The minutes of the management review. Made as the work happens, so the record shows what you did and when.
The standard calls all of this an information security management system, or ISMS. It is the decisions, routines and records, run on a schedule and reviewed by someone senior. That is what gets audited.
Why the first audit finding is nearly always access
Access grows the way most businesses grow, by adding and rarely removing. A manufacturer we worked with had a mix of office systems, plant software and a handful of cloud tools.
People changed roles and kept their old permissions. Contractors came and went, and their accounts mostly stayed. A few shared logins existed because it had once been easier.
The trigger was ordinary. An internal review asked who could access one system, and nobody could answer with confidence. That uncertainty, across every system they ran, was the real risk.
This is why access is found first. An auditor picks a system, pulls the list of users, and asks you to account for each name. A leaver still on the list, or a shared login, is a finding: the auditor’s word for a gap they write up.
We pulled the manufacturer’s access into one picture, system by system. The dead weight was obvious: leavers, departed contractors, permissions left from old roles. We removed it, confirming need as we went, so nobody lost access they used and nothing broke mid-shift.
Shared logins became named accounts. Then we put in joiner, mover and leaver steps, so access changes when a job does, and a periodic review to keep it that way.
Security people call this least privilege: each person holds the access their job needs and no more. It is a habit, kept by routine. The case study on how we cleaned up years of built-up access at a manufacturer has the detail.
Suppliers are the same problem one step removed. Each tool, agency and integration holds some of your data or reaches into your systems, sometimes more than its job needs. Rank them by what each could reach, and start at the top.
Pull each connection back to what that supplier needs. Then disconnect the vendors you no longer use, which is the step most often forgotten. A short routine for new suppliers keeps the list current.
The bad day, and the evidence that you were ready
The standard also asks what happens when something goes wrong. For an operations business the common case matters most. Phishing is an email that tricks someone into opening a bad file or typing in a password. One such email can freeze the systems the whole operation runs on.
A logistics operator in the GCC we worked with was worried about that case. Their backups had never been restored in a real test, so nobody knew whether they would work. Systems were poorly separated, and sign-in relied on passwords alone.
We started with the backups, because they decide how a ransomware incident ends. Ransomware is software that locks your files for payment. We kept a copy where ransomware on the main network could not reach it, and restored it in a test.
Then we separated the systems that did not need to talk to each other, so an infection cannot spread freely. We added multi-factor authentication, a second check at sign-in, so a stolen password is not enough on its own.
The plan should be short, with clear roles: who decides to take a system offline, who talks to customers, who talks to a regulator. Then rehearse it in a tabletop exercise: a realistic scenario talked through with the people who would be in the room, no live system touched.
When we ran one with a fintech, it turned up an out-of-date contact, an unclear handoff and a backup assumption nobody had checked. Each was still cheap to fix. Those gaps, and the record of closing them, are the kind of evidence an audit looks for.
What an auditor asks to see, and who issues the certificate
The certificate comes from an external certification body, after its audit. ISO itself certifies nobody. Ask for a body that is accredited, which means an independent accreditation body has checked its competence.
Our part is the work before the audit: getting a business’s practices and evidence into shape. The auditor starts from your documents and asks for the records behind each.
Expect to be asked for the list of systems and who can reach each. The record of the last access review. The supplier list. The risk assessment, with the reason each control is there. The incident plan, its rehearsal notes, and the backup restore log. The management review minutes.
Then come the samples. A leaver from last quarter: when was the account closed? A new supplier: who checked what it could reach before it was connected?
Certification runs on a multi-year cycle, with shorter check-up audits, called surveillance audits, in the years between. A programme that only runs in the week before an audit fails at the next one.
When a customer asks whether you are certified, the wording matters. Say “certified to ISO/IEC 27001:2022”, the standard’s full name, and name the certification body that issued it. The customer can check with that body. You can check a supplier’s certificate the same way.
If your business handles personal data in India, the DPDP Act is a separate legal duty, whether or not you pursue ISO 27001. We have written about what the DPDP Act means for your business systems.
Where to start
You do not need to buy anything this week. Pick one system that matters, ideally the one your customers would ask about first. Pull the list of every account on it. Next to each name, write who they are, whether they still work with you, and why they need that access.
Then take the few suppliers that reach furthest into your systems, and note what each holds and can reach. Finally, ask when a backup was last restored in a test. Taking one every night does not tell you it works.
What you find is your gap list, and the start of the inventory. It is also where our cybersecurity and compliance work begins: the inventory, the access cleanup, and the routine that keeps both current.
If you want to know how far you are from ISO 27001 before committing to anything, message us on WhatsApp from the contact page. Tell us roughly what you run and who is asking, and we will talk through what the first month of work looks like.