Situation
A technology startup in Vilnius, Lithuania, with about 20 employees, builds a SaaS product for companies in the finance and insurance sector. The team is strong in engineering, the product runs in the cloud, and the clients are mid-sized and large companies in Lithuania and Scandinavia. The sales cycle is long, and every serious client sends a security questionnaire before signing: dozens or several hundred questions about policies, access management, incident management, suppliers and business continuity.
The turning point came when the startup lost a tender at a Scandinavian insurance company. The buyer liked the product, but the answers in the security questionnaire were “we do not have a document, but we do it” in almost every row, while a competitor held an ISO 27001 certificate. The buyer’s reply was polite and clear: come back when you have it.
There was no security person at the company, and hiring one just for a questionnaire made no sense. The CTO understood security, but writing policies, keeping a risk register and speaking the language of audits was not his job, and somebody had to build the product. They needed someone who would run security as a function, not as a project, and who would not have to be paid like a full-time hire.
What was needed
- An information security management system that meets ISO 27001 requirements, sized for a 20-person company, not a corporation.
- Documents that can be presented to clients: policies, a risk register, an incident plan, supplier assessments.
- The ability to complete client security questionnaires in days, not weeks.
- Readiness for a certification audit within a year, so that at the next tender the answer would at least be “audit date scheduled”.
- Minimal engineering time, because product development cannot stop.
What we did
Month 1: assessment and risk register
We started with an IT security audit against the ISO 27001 control list: what the company already does in practice, what is done but not documented, and what is missing entirely. It turned out that the technical controls were better than we expected: code reviews, MFA, encryption, logs. What was missing was the management layer: who is responsible for what, how risks are assessed, how incidents are handled and how suppliers are checked.
Together with the managers we built a risk register: about thirty risks with owners, ratings and agreed actions. The register became the basis for everything that followed, because an ISO 27001 auditor asks first not about the policies but about where they came from.
Months 2-3: policies and processes
We wrote fourteen policies and procedures: information security policy, access management, cryptography, secure development, incident management, business continuity, supplier management, acceptable use rules and others. Each is a few pages, with a responsible person and a review date. The principle was simple: a document says only what the company actually does or commits to doing from next week. A policy that is not followed is worse for an audit than no policy at all.
The hardest part was supplier assessment. The startup used several dozen cloud services, and some had been bought with a card with no contract at all. We listed them, sorted them by data sensitivity, collected supplier security evidence for the critical ones and replaced two services with ones that had something to show.
Month 4: incident plan and exercises
We tested the incident management plan with a tabletop exercise with the whole team: the scenario was access keys leaked in a public code repository. The exercise showed that nobody knew who informs the clients and within what time. We extended the plan and prepared client notification templates in advance.
Month 5: questionnaire library and internal audit
From the policies and the risk register we built a library of answers to the most common client questionnaire questions, with links to documents and evidence. We carried out an internal audit against the ISO 27001 requirements and recorded the nonconformities and a plan to correct them. From this point the vCISO service continues as an ongoing one: a monthly meeting with management, a review of the risk register, completing new questionnaires and preparing for the certification audit.
Result
Client security questionnaires are now completed in 3 working days, including the CTO’s review. Before, this took weeks and ended with empty rows. In the last two months three questionnaires were completed, one of them from the same sector where the tender had been lost.
There are 14 approved policies and procedures, all with owners and review dates, and all available to employees in one place. The internal audit nonconformities are closed, readiness for the certification audit is in place, and the date is agreed.
The number of security hires at the company is 0. The security function is performed by a vCISO for agreed hours per month, and the engineers went back to the product. The CTO calculates that in five months he spent less time on security than he had previously spent on a single lost questionnaire.
We thought ISO 27001 was a pile of paperwork for big companies. It turned out to be just a list of questions we had to answer anyway.
What we would advise in a similar situation
- Do not start with policy templates. Start with the risk register: the policies follow from it naturally, and the auditor can see the link.
- Write only what you do. An auditor finds a document that is not followed within the first hour.
- Sort out suppliers early: cloud services bought with a card are the most common nonconformity at small technology companies.
- Separate the security function from the head of engineering, even if he understands it. His time costs you the product.
