ISMS in a week

Speed run to certification

Previously I wrote about the departmental ISO-27001 journey at Serverside.ai.

This blog post is about how to set up rails in a startup, to make the transition to ISO-27001 certification seamless. With NIS-2 and more awareness this becomes a crucial topic. This is the full text version of this post.

Introduction: ISO-27001 and security in general means that your company can continue to provide a service at a specific quality, “come what may”. It stipulates that processes must exclude risk by considering nasty eventualities and planning to deal with these. It pledges to implement a beneficial cycle of continual improvement. Here are the specifics against this backdrop based on my post of a year ago:

1. Top-level buy-in: The call for security awareness comes from the top. In a product oriented software startup this means the whole company must understand security as a key product feature.
2. Make it your DNA: By deeply understanding what the process entails, the company can be engineered to achieve safety affordably.
3. Live it!    Good habits in product development mean small daily pay-ins to the security certification and audits. The latter becomes something you look forward to, because the experts actually make sensible suggestions you want to follow, rather than a month of toil and late nights.

Process automation only comes in in the third step: specific ways of using Tooling (my favourites: Atlassian), AI documentation assistants, and the afore mentioned good habits (e.g. setting up an ISO-27001 calendar).

I have been asked how one can make head-way with point 2. Here is a quick dive into a speed run to your ISMS within 7 days for a startup (5 people), based on confluence (you can use any other tool, such as NotebookLM, Notion, and they all have pros and cons):

• Ultimately we have to prove that the company controls risk according to the ISO-27001:2022 controls.
  • Buy the standard, it’s inexpensive. You need it for the cert.
• Policies vs standards vs guidelines:
  • Policies describe the processes the company will adhere to. These describe how a company keeps information safe and services operating. They may also contain possible sanctions to apply etc. The policies have to cover all the controls, but initially we want to apply Pareto progressive implementation. Aim for the most important 80%, and stub 20%. You must have this documentation.
  • Guidelines: this is the first point of implementation. Here you describe your waterfall or agile process, delivery standards, etc. Much of this documentation can be pulled one-to-one from your ticket system’s documentation together with software coding guidelines, as expressed in .eslintrc, pylint.rc/pyproject.toml, etc. Keep a master Lint file and process doc, version it. It should be part of your on-boarding doc, so don’t make it TL;DR. Collating this information should just less than an hour and by the end you will have checked several boxes:
    • On-boarding documentation
    • Process understanding
    • Coding standards clarity
  • Standards set the bar the team has to jump over. You need a plan that lays this out, including automation, but you will still achieve a certification without actually having implemented the plan. Some essentials that good devs will do without thinking about it are:
    • Logging and Observability standards
    • Error handling standards
    • Linting
    • Testing standards Ask Claude to distill these standards from your code base. Ideally, each bullet is a half page document that developers will love to refer to when opinion arguments break out.
  • While a software development startup must focus on its core business, spare a thought for your CRM with supplier and customer data. As a startup you may be using a spreadsheet; and in this case, make sure it supports versioning and ensure that you add metadata for each change (e.g. why was an NDA not extended). Again, if you don’t have time: put it on the roadmap.
• The Risk Management Meeting, do this 6-monthly: this is the core operational ceremony of ISO-27001. It is a controlled 360 degree look at all the most likely things that can and will go wrong, with the current company status. The promise of this ceremony is to lower the likelihood of the most urgent risks. Beside the regular risk management meetings with the entire leadership, the operational leadership (CTO) needs to treat this as a living document, and update it with each incident, or according to changes on the market (new disruptive technology from a competitor? zero day weakness?).
  • Risks need to be mapped to controls, which puts the risks in the orbit of policies.
  • Risks need to be treated, which underlines that one conforms to the ISO required controlling.
• The internal audit, do this annually: Here’s a good short-cut that will cost your ISMS leader (in a startup company this might be the CTO, or CPO) only two days of work (the first time you do it, thereafter less): get an ISO Audit checklist and fill it in yourself. It will only take you 16 hours if you do it correctly, and by the end you will have:
  • Checked each ISO control;
  • Built a document overview, by sorting all your doc into the same confluence store hierarchy;
  • Built a roadmap detailing in which order you will fill further gaps;
  • Have the basis for a Management review.
• Management kick-off /-review:
  • This is the official meeting where the CEO and founders solemnly swear that the company is ISO-27001 compliant in an initial manner and commited to continually improving (PCDE cycle).
  • In this review, they
    • check that all controls are accounted for,
    • approve the resources needed for the roadmap,
    • check that the risk level is acceptable and
    • check that all recommendations from internal and external audits have been implemented.
• External audit: if you haven’t yet, you should now approach a certifying authority to get the official certification and an auditor, who may accompany you on the journey of improvement for many years to come.