GUIDE TO STANDARDS

A standard, a framework and legislation are not the same thing

This is the core of the whole page and also the most common source of bad decisions. ISO 27001, CIS Controls, NIST CSF, SOC 2, the GDPR and the Czech Cybersecurity Act routinely appear in the same sentence, as if they were interchangeable routes to the same goal. They are not. They differ in who issues them, what they evidence and what happens if you fail to meet them.

A standard is a document of requirements with a certification scheme behind it. Under ISO/IEC 27001 the assessment is whether you run a working information security management system, and the outcome is a certificate issued by an independent certification body. A catalogue of controls — typically CIS Controls — is an ordered list of specific things that can be done, sorted by what stops the most attacks. Nothing is certified against it. A management framework — NIST CSF — prescribes neither controls nor requirements; it provides a shared language for describing the current state, the target and the priorities, and its main value is that it can be explained to the board. An attestation — typically SOC 2 — is a report by an audit firm on how controls are designed and whether they operated effectively; it is not a certificate and no certification body issues it. And legislation is law: Act No. 264/2025 Coll. and its decrees, the CRA, DORA or the General Data Protection Regulation. You do not meet that voluntarily, and failure is dealt with by a supervisory authority, not by a business partner.

The practical consequence: a certificate against a standard does not prove compliance with legislation, and complying with legislation does not earn you a certificate. A catalogue of controls registers you nowhere, and a management framework on its own implements not a single control. When that difference is not cleared up at the start, the usual situation follows — a company pays for certification in order to solve a regulatory obligation and, a year later, finds that it still has to run a gap analysis against the decree and register.

• ISO/IEC 27001 — a certifiable standard. Issued by ISO and IEC, the text is paid for. It evidences that a management system works and has been audited by a third party. The market enforces it, not the state.
• CIS Controls — a catalogue of controls. Issued by the Center for Internet Security, the text is available free of charge under licence terms. At most it evidences your own view of your own state; no certification exists.
• NIST CSF — a framework for management and communication. Issued by the US NIST, the text is public. It serves to describe the current and the target state and to hold a conversation with the board, not to audit compliance.
• SOC 2 — an attestation. The engagement is run by an audit firm under the attestation standards of the US AICPA and the output is a report with an opinion, not a certificate. It evidences your state to a customer, usually under a confidentiality agreement.
• The act and its decrees — legislation. Issued by the state, the wording is binding and available free of charge in the e-Sbírka. NÚKIB enforces it and non-compliance is an administrative offence, not a commercial risk.
• NÚKIB guidance — non-binding pointers. No penalty and no certification, but it is written for the Czech environment and it shapes what the regulator understands by "common practice".

A shortcut we use in the first meeting: write down one sentence about who you want to evidence what to. A customer before signing a contract, a supervisory authority, an insurer, or your own board. The answer to that question decides the choice of framework more reliably than the size of the company or its industry.

ISO/IEC 27001: what is actually certified

First the frequent misunderstanding: it is neither the company nor a product that is certified, but the information security management system (ISMS) within a defined scope. The organisation sets that scope itself and it is stated on the certificate. A certificate for "the development centre in Brno" and a certificate for an entire group are two very different documents, even though both carry the same standard number. When you assess a supplier's certificate, read the scope before you look at the certification body's logo.

The standard has two parts. The requirement clauses deal with the context of the organisation, leadership, planning including risk assessment and treatment, support, operation, performance evaluation and improvement. The second part is Annex A — a list of 93 controls split into four themes: organisational, people, physical and technological. We do not give the wording of the controls here, because it is protected by ISO copyright; guidance on implementing them sits in a separate standard, ISO/IEC 27002, which is structurally aligned with Annex A. In 2024 the standard also received an amendment addressing climate-related issues — it touched the opening clauses on context and interested parties, not Annex A.

Annex A controls are not implemented across the board. They are selected on the basis of the risk assessment and the selection is justified in the Statement of Applicability (SoA), which records for each control whether it applies and why. That is exactly the document the auditor asks about, together with whether it matches reality — an SoA that applies all 93 controls "to be on the safe side" is a warning sign, not a mark of thoroughness.

ISO does not issue certificates. They are issued by a certification body accredited by a national accreditation body — in the Czech Republic that is the Czech Accreditation Institute. The audit has two stages: the first assesses readiness and documentation, the second how the system works in operation. Once the certificate is issued, a three-year cycle runs with surveillance audits, and recertification before the cycle ends. That is a recurring cost, not a one-off one.

• What the certificate evidences: that within the stated scope a management system exists, risk assessment is running, controls are selected and justified, and that an independent auditor verified it.
• What it does not evidence: that you are secure. A certificate is about management, not about the resilience of a particular application — it replaces neither a penetration test nor a threat model.
• What it certainly does not evidence: compliance with legislation. A certificate is not evidence for a supervisory authority and no Czech legislation lists it as proof of compliance.
• When it makes sense: customers require it in tenders, you sell abroad, or you need one answer to dozens of security questionnaires a year.
• When it is pointless: nobody asks you for it, your main issue is regulation, or the company is so small that the annual cost of keeping the system alive would swallow the capacity that should go into security itself.

A scope can be written so that it passes the audit and still fails to cover what the customer is asking about. That is why we start with the scope and the Statement of Applicability rather than with buying tools — when the scope has to be fixed after the first audit, you pay twice.

CIS Controls: a catalogue of controls with three tiers

CIS Controls are a catalogue of specific controls from the Center for Internet Security. The current version 8.1 contains 18 Controls broken down into 153 Safeguards; compared with version 8 it added a governance view and reworked the descriptions of asset classes. What matters is that this is neither a standard nor legislation: nothing is certified against CIS and nobody enforces it. It is a working list.

The value of the catalogue lies in the tiering. The controls are split into three Implementation Groups. IG1 is basic hygiene — 56 Safeguards that, according to CIS, every organisation should be able to manage; the typical addressee is a small or mid-sized company without a security team of its own, protecting mainly employee and financial data and unable to absorb long outages. IG2 builds on IG1 for organisations that already have someone dedicated to security and handle customer data. IG3 covers the whole catalogue and assumes in-house specialists. The groups are not skipped: IG2 includes IG1, IG3 includes IG2.

For a small company this is the cheapest sensible start. There is no standard to buy and no auditor to pay, and the work splits into items that can be ticked off. Above all, the ordering follows how attacks actually begin — knowing what you have, and order in accounts and permissions, sit at the top of the catalogue for the same reason they turn up as the first finding in every other security review.

We deliberately do not give the wording of the Controls or the Safeguards. CIS Controls v8.1 are published under the Creative Commons Attribution-NonCommercial-No Derivatives 4.0 licence: it allows distribution for non-commercial purposes, prohibits the distribution of modified versions and makes commercial use subject to prior consent from CIS. The website of a commercial company is a commercial context, so we describe them in our own words and link to the original.

• Asset inventory. Knowing which devices and which software run in the environment, and having a process by which a new item gets into the inventory and a retired one drops out of it.
• Accounts and permissions. Removing access when people leave, separate administrator accounts, multi-factor authentication wherever access comes from outside.
• Secure configuration and updates. Default passwords, unused services, patching pace and how it is measured.
• Backups and restores. Not only that backups exist, but that restores are tested and that an attacker who has taken over the domain cannot reach the backups.
• Logging and response. Logs that somebody actually reads, and a written incident procedure including who calls whom outside working hours.
• People and suppliers. Training built on what really lands in mailboxes, and a basic assessment of suppliers who have access to your environment.

The list above and the description of the Implementation Groups are our own text, not a quotation from the catalogue. Described on the basis of CIS Controls Implementation Groups by the Center for Internet Security, available under the CC BY-NC-ND 4.0 licence. For the exact wording of the Safeguards and for their assignment to groups, go to the CIS website. If you want a quick picture: walk through the first three points in your own environment and measure how long it takes you to answer. Most companies get stuck on the first question, not on the last one.

NIST CSF 2.0: a framework for management and for the conversation with the board

The NIST Cybersecurity Framework is a US framework that has long been used outside the USA as well. Version 2.0 from February 2024 brought two things that make it worth attention in the Czech Republic too. The first is the sixth function, Govern, which was added to the original five — Identify, Protect, Detect, Respond, Recover — and brought into the framework what decides the most in practice: who is accountable for security, how risk decisions are made and how suppliers are managed. The second is the wider reach — CSF 2.0 is no longer written only for critical infrastructure, but for organisations of any size.

The structure has three levels: six functions split into 22 categories, and those into 106 subcategories. The subcategories are written as outcomes the organisation should achieve, not as specific controls — the framework does not say "deploy this tool", it says "have this property". Specific controls are attached to them through so-called informative references, which link to other catalogues and standards.

The practical strength of the framework lies in its profiles. You describe the current state and the target state in the same structure; the difference between them is both an action plan and a picture that can be shown to the board. On top of that the framework offers Tiers, describing how formalised risk management is in the company. It is not a quality rating, it is a description of approach — and for a conversation with the board it works better than a table of unmet controls.

The framework is free of charge. NIST publications created by its employees are not subject to copyright protection in the USA and no permission is needed to reprint them; outside the USA they are protected, and for reuse NIST points to a written request. That is why we describe it in our own words here and link to the original.

• Govern — expectations, roles, accountabilities, policy and risk management including the supply chain. The function that decides whether the rest survives longer than a single project.
• Identify — understanding the environment and the risks: assets, dependencies, vulnerabilities, priorities.
• Protect — the controls that reduce likelihood and impact: access, data protection, technology resilience, training.
• Detect — the ability to notice. Monitoring, event analysis, thresholds.
• Respond — what happens after detection: analysis, containment, communication, records.
• Recover — restoring operations and learning from the incident.

In our maturity assessments we most often use the CSF as the backbone of the output — not because it is more precise than other frameworks, but because it lets you show the gap between where the company is and where it wants to be on a single page. Budget decisions are made over a picture like that, not over a list of 153 items.

SOC 2: an attestation, not a certification

When a supplier writes "we hold a SOC 2 certificate" in a questionnaire, it is not merely imprecise — it is a signal that they have never worked with the document themselves. SOC 2 is not a certification and no certificate comes out of it. It is an attestation engagement under the standards of the US professional body AICPA: the organisation being assessed describes its system and controls and takes written responsibility for that description, an audit firm (CPA) examines it and issues a report with an opinion. There is no certification body handing out a stamp and no public register where the document could be checked. The output is a document you have to obtain and read.

The criteria used for the assessment are called the Trust Services Criteria and come in five categories: security, availability, processing integrity, confidentiality and privacy. Security forms the so-called common criteria and is part of every engagement; the remaining four categories are added according to what the organisation promises its customers. The organisation being assessed therefore chooses the range of criteria itself — and that is the first thing you establish when reading the report. A report covering security only says nothing about the availability of the service, even if it is otherwise free of findings.

The difference between type 1 and type 2 is what matters. A type 1 report (Type I) assesses the description of the system and whether the controls are suitably designed — as at one specific date. It says nothing about whether the controls ever actually worked. A type 2 report (Type II) additionally assesses the operating effectiveness of the controls over a defined period: the auditor tests samples from across the period and describes the test results in the report. The length of the period is set by the engagement; in practice it tends to be six to twelve months, sometimes shorter for a first report. In one sentence: type 1 says "this is how it was built as at a date", type 2 says "this is how it demonstrably worked from date to date".

A SOC 2 report is not a public document. It contains the description of the system, the tests performed and their results, so it is intended for a defined group of recipients and in practice it is handed over under a non-disclosure agreement. The freely distributable variant is SOC 3 — a shorter report without test detail that may be published. A badge on a supplier's website therefore says nothing about the content of the report: behind it sits either SOC 3 or just a graphic, not the document you need for your assessment. And although this is a US standard, in Europe it is a routine part of due diligence on cloud and SaaS suppliers: European companies ask suppliers for it, and a Czech supplier selling into the United States will get it as a contractual condition.

• The scope of the report. Which services, systems and locations it covers, and whether the one you actually buy from the supplier is among them. A report on one platform says nothing about the same supplier's other products.
• Type and period. For type 2, above all the end date of the period covered. A report older than a year reads as a historical document; for the gap between the end of the period and today you can ask for a bridge letter. That, however, is written by the supplier's management, not by the auditor, and its weight matches that.
• Criteria in scope. Whether availability, confidentiality, processing integrity or privacy are included alongside security. If you are building the availability of your own service on this supplier, a missing availability category is an answer in itself.
• The auditor's opinion. Unqualified, qualified, adverse, or a disclaimer of opinion. A qualified opinion is not an automatic disqualification, but you have to read what the qualification concerns and whether it touches exactly the thing you are assessing the supplier for.
• Findings and exceptions in the tests. A type 2 report has a section describing the tests and their results. That is where exceptions show — how many there were and how the organisation responded to them. This section is the core of the report; the cover page and the audit firm's logo say nothing.
• Controls on your side. Reports usually list complementary controls that the customer has to implement for the supplier's controls to make sense — managing your own accounts, configuring encryption, reviewing permissions. If you do not implement them, the gap is on your side and it will show up as a finding in your own audit.
• Subservice organisations. Whether key subcontracted services are included in the report or carved out of it. For carved-out ones you have to ask for separate evidence, otherwise you only assess part of the chain.
• Other information provided by management. A closing section that the auditor did not test — it usually contains responses to findings and remediation plans. It reads as a statement by the supplier, not as verified information.

For supplier assessment a type 1 report is a weak argument: it evidences the design of controls as at one date, not that anyone followed them. It makes sense for a new service in its first year, as a signal that the organisation is preparing for attestation. But when a supplier sends type 1 repeatedly for several years running, that is information in itself. And always ask for the full report — the cover page tells you neither the scope, nor the period, nor the findings.

The NÚKIB Minimum Security Standard and what comes closest today

The Minimum Security Standard (MBS) was created in 2020 by NÚKIB, NAKIT and the Ministry of the Interior and aimed precisely at organisations that fell outside the Cybersecurity Act but still needed to deal with security — municipal offices, schools, healthcare providers, smaller companies. The document ran to roughly fifty pages and had two parts: a management part on setting up processes and securing leadership support, and a technical part written for administrators. From an official source we can only evidence the first release, version 1.0 from July 2020; the links circulating on the internet point to a later version 1.2, which we could not open on the NÚKIB website as at 8 August 2026, so we make no claim about its release or its date. The document was never binding — it was non-binding recommended guidance.

The situation as at 8 August 2026 has to be stated plainly, though: the MBS is no longer listed among the NÚKIB supporting materials and we were unable to download the original file from the authority's website, even though other documents from the same location download normally. Treat the links to "MBS v1.2" that circulate on the internet and in our own older materials as links to a historical document. Its content has not aged dramatically, but it cannot be cited as current guidance from the authority.

What replaced the MBS from the authority's side: after Act No. 264/2025 Coll. took effect, NÚKIB issued a manual for providers of a regulated service in the lower-obligation regime (version 1.0 of 31 March 2026, update 1.1 of 2 June 2026). It explains Decree No. 410/2025 Coll. through examples, describes the most common mistakes and includes a sample overview of security measures that entities in the lower regime have to maintain. It is written for regulated entities, but nothing prevents a company outside regulation from using it as guidance — and today it is the closest Czech substitute for what the MBS used to do.

The difference from the decrees is fundamental and worth repeating. Decrees No. 409/2025 Coll. and No. 410/2025 Coll. are binding and compliance with them is demonstrated to the supervisory authority. The manual is an interpretation: it imposes nothing and changes nothing, and where it diverges from the text of the decree, the decree prevails. The MBS was guidance with no addressee in any legislation.

• Who the MBS was for: organisations outside the scope of the Cybersecurity Act that wanted a baseline in Czech and at no cost.
• What to do with it today: it can be used as a reference, but not as current guidance from the authority — it cannot be found among the valid supporting materials.
• What is available today: the manual to the decree for the lower regime (v1.1, 2 June 2026), the interpretation glossary, guidance on cryptographic algorithms and other NÚKIB supporting materials.
• For companies outside regulation: more practical than hunting for a withdrawn document is to start with the lowest CIS Controls Implementation Group and with the recommended minimum aimed at exactly this case.

If the MBS reappears on the NÚKIB website or is released in a new version, this section and one FAQ question change — nothing else on the page is affected. We verified its availability on 8 August 2026.

GDPR: legislation, not a framework or a standard

The GDPR regularly lands in the same sentence as ISO and CIS in conversations, which is why it gets a short slot here. It belongs to a different category, though: the General Data Protection Regulation is a regulation of the European Union — Regulation (EU) 2016/679, directly applicable since 25 May 2018 and supplemented in the Czech Republic by Act No. 110/2019 Coll. Its obligations arise on their own, regardless of which security framework a company picks, and they are supervised by the Office for Personal Data Protection, not by a certification body. A certificate therefore cannot discharge the regulation, because there is nothing to certify — it is law, not a scheme.

Where the regulation meets security frameworks is mainly Article 32 on security of processing. It calls for technical and organisational measures appropriate to the risk and names, among other things, pseudonymisation and encryption of personal data, the ability to ensure the ongoing confidentiality, integrity, availability and resilience of systems, the ability to restore availability of the data after an incident, and a process for regularly testing and evaluating the effectiveness of the measures. Those are activities that exist both in an ISO/IEC 27001 management system and in the CIS Controls catalogue — work on them feeds into Article 32 and does not have to be done again from scratch.

Watch out for what follows from that, though. Article 32(3) says that adherence to an approved code of conduct or an approved certification mechanism may be used as an element by which to demonstrate compliance with the requirements of that article — that is, as supporting evidence, not as discharge of the obligation. Article 42(4) adds that certification does not reduce the responsibility of the controller or the processor. And beyond that: certification under Article 42 is an instrument of the regulation itself, with criteria approved by the supervisory authority. Neither an ISO/IEC 27001 certificate nor a SOC 2 report is certification under the GDPR, even though they are occasionally presented that way.

Closer to personal data protection sits ISO/IEC 27701, the standard for a privacy information management system. The 2019 edition was an extension of ISO/IEC 27001 and 27002; the 2025 revision turned it into a standalone standard that can be implemented outside an information security management system as well. Even that one does not cover the whole regulation, though: legal bases for processing, information duties, data subject rights, records of processing activities and data protection impact assessments are not questions a security standard answers.

• How it is met: by demonstrable procedures under the regulation. The only supporting evidence can be approved certification under Article 42 or an approved code of conduct — not an ISO certificate and not a SOC 2 report. Neither of them replaces the obligation itself.
• What can be reused from security frameworks: access management, encryption, backup and restore, supplier management, incident records and incident handling, testing the effectiveness of controls.
• What you will not find in the frameworks: legal bases for processing, information duties, data subject rights, records of processing activities, impact assessments, rules for transfers to third countries.
• Two different notifications of one event: under Article 33, a personal data breach is notified to the Office for Personal Data Protection without undue delay and, where feasible, within 72 hours of the controller becoming aware of it, unless it is unlikely to result in a risk to the rights and freedoms of natural persons. A cybersecurity incident affecting a regulated service is reported to NÚKIB under the Cybersecurity Act. One event can trigger both, and neither the deadlines nor the addressees line up.

This section is orientation, not an interpretation of the regulation — treat the GDPR as a separate topic with its own supervisory authority. A practical rule from our projects: anyone dealing with personal data protection and the Cybersecurity Act decrees at the same time should keep one asset inventory and one incident register and generate outputs from them for each addressee separately. Two parallel registers always drift apart, usually at exactly the moment something has to be reported.

Where frameworks and legislation overlap and where they do not

The most useful sentence on this page: certification against ISO/IEC 27001 does not automatically mean compliance with Decree No. 409/2025 Coll., and complying with the decree will not get you a certificate. That is not a formality or excessive caution — they are two different types of document with different addressees. The standard says "have a working management system and select controls according to risk". The decree says "do this specific thing, to this extent, and evidence it". Where the standard leaves room for judgement, the decree often fixes a parameter.

That does not mean the work has to be done twice. On the contrary — a substantial part of the underlying material is shared and the difference lies mainly in what is additionally evidenced and to whom. If you have an ISMS whose scope covers the regulated service, then in our experience a large part of the route to the higher regime is behind you; the rest is evidencing the specifics. It works less well in the opposite direction: a company that built its security purely to the decree usually lacks what a certification auditor will ask for — a coherent risk assessment across the scope, a Statement of Applicability, an internal audit of the management system and a management review.

The same logic applies to other legislation, only with different gaps. Under the CRA, what is assessed are the properties of the product and the evidence of how they came about — an ISO/IEC 27001 management system helps with the processes, but it replaces neither product-level risk assessment, nor the software bill of materials, nor the technical documentation. DORA, in turn, has its own register of information and contractual requirements that do not fall out of the standard. And no framework will handle registration with the supervisory authority or the filing of a report within the deadline.

The practical consequence for planning: decide which document is the primary one and relate the others to it. When a company has a statutory obligation and commercial pressure for a certificate at the same time, legislation leads — it is enforceable — and certification is built on the same records. The other way round, you spend a year working on a certificate while the statutory deadlines pass.

What you deliberately will not find here is a table of the "control X of the standard corresponds to section Y of the decree" kind. Such pairing looks useful, but it invites people to present a ticked box in one column as a discharged obligation in another — while the scope, the depth and the question of what is evidenced to whom all differ. The relationship between a specific control and a specific requirement can only be assessed honestly over a specific company and its scope; a generic table cannot do it, and with protected standard texts it could not be published anyway. What is useful is the level one floor up: which activities can be reused and which cannot.

• Reusable as is: risk assessment and the risk register, asset and supplier inventories, access and change management, backup and continuity, incident records, training, management review. They are the same activities — only different evidence is pulled from them for each addressee.
• Reusable after adjustment: technical controls. Legislation tends to be more specific than a standard and fixes a parameter where the standard leaves room for judgement. The control therefore exists, but it has to be tuned and evidenced in the form the legislation requires.
• Reusable as method, not as conclusions: independent reviews. The plan, the methodology and the record of findings can be kept once. The scope, the requirements on the independence and qualification of whoever performs the review, and the form of the output are set separately by each addressee — for the higher-obligation regime the decree states this explicitly.
• Not reusable at all: registration with NÚKIB, incident reporting within the deadlines and by the prescribed route, mandatory formalities towards the supervisory authority. No framework arranges or replaces any of that.
• For products and in the financial sector, on top of that: under the CRA, product-level risk assessment, the software bill of materials, the support period and technical documentation; under DORA, the register of information and contractual provisions. A management system is a precondition, not a substitute.

When something is done twice, it is usually not because it could not be shared, but because two different people in the company own it and each keeps their own spreadsheet. That is why our projects start with one register of controls and one register of evidence, to which the addressees — standard, decree, customer questionnaire — are only then assigned. If you are looking for a tool instead of spreadsheets: that is exactly what our GRC platform Observa does, seven days free and with no payment card.

How to choose according to what you need to prove

The common mistake is to pick a framework by the size of the company — "we are small, so CIS; we are big, so ISO". Size affects the effort, not the choice. What decides is what has to come out at the end, and there are essentially four options.

The four situations below can be combined, just not all at once. If more than one applies to you, sort them by which one has a deadline — legislation always has one, a commercial requirement usually does, self-improvement almost never.

• The customer asks for a certificate. First check what they actually want: an ISO/IEC 27001 certificate, a SOC 2 report, a completed security questionnaire, or evidence of specific controls. For a questionnaire and for evidence of controls, the answer can be assembled from existing documentation in weeks rather than months. If it really is a certificate or a SOC 2 report and it is a contractual condition, budget for the whole run — for certification including the three-year cycle and surveillance audits, for a type 2 report including the period covered, which has to elapse first. Neither is a one-off exercise.
• We need to get our bearings. This covers companies that do not know where they stand. The fastest way to show it is a NIST CSF profile or an assessment against CIS: both give a picture in days to weeks and require no decision about certification. The choice between them is about the audience — the CSF presents better to the board, CIS gives more specific tasks to engineers.
• We are meeting a regulatory obligation. The legislation leads. A framework is used as an aid for structure and to make the evidence usable elsewhere, but the source of requirements is the decree or the regulation. The route is a gap analysis against the legislation, a remediation plan, evidence. Certification is a possible by-product, not the goal.
• We want to improve and have no obligation. The cheapest and fastest route is the lowest CIS Controls Implementation Group. Nothing is registered anywhere, nothing is certified, and the effect shows in operations. If regulation or a customer requirement arrives later, none of it is thrown away — you only add the evidencing on top.
• When to do none of this: when the company does not have the basics of operations under control — backups, updates, account management. A framework imposed on chaos from above produces documentation, not security. This is the only case where we recommend postponing even the cheap options and starting with operations.

Write the decision down together with the reason and the date. In a year somebody else will ask — a new customer, an insurer, or your own management approving a budget — and the sentence "we chose X because we needed to evidence Y" saves a second round of the same debate. When the choice stalls, it tends to be the content of the first consultation: work out who has to be shown what, and choose accordingly. And if you want to track the state continuously instead of taking a one-off snapshot, we have our own GRC platform for that, Observa — seven days free in limited scope, no payment card and no commitment, from CZK 2 990 per month thereafter.

What it costs and what eats the most calendar

We do not quote specific prices here, because they differ by a factor of two even between comparable companies and a certification body's quote depends on the scope. What we do give is the structure of the costs, because that is always the same and the surprises tend to sit in its less visible parts.

With ISO/IEC 27001 certification you pay in three streams. The first is the certification body — the price follows from the number of people within the scope of the management system and the number of sites; the rules by which bodies calculate audit time are in ISO/IEC 27006-1. The second is preparation: internal time from people who used to do something else, plus external support where needed. The third is maintenance — surveillance audits in the intervening years and recertification before the end of the three-year cycle, plus time for an internal audit and a management review every year. Anyone budgeting only for the first year has budgeted roughly half.

The most expensive item in calendar terms is usually not implementing the controls, but the time the system has to run in order to leave records behind. At stage two the auditor does not want to see only a policy, but also that an internal audit and a management review took place and that records from normal operation exist. That cannot be sped up with money — it is calendar time, and it is the main reason why the route to a certificate is measured in months, not weeks.

With CIS Controls and NIST CSF the structure is simpler: no auditor, no fee for the text, the cost is time and possibly tools. That is also why you can start with them immediately, and why they are a sensible first step even for a company heading towards certification — the work is not thrown away, evidence and formalities are simply added to it later.

• One-off: preparing documentation, risk assessment, implementing the missing controls, the first certification audit in two stages.
• Every year: surveillance audit, internal audit, management review, updating the risk assessment and the Statement of Applicability.
• Every three years: recertification with a scope close to the first audit.
• Hidden item: maintaining the scope. When the company grows or changes its structure, the scope of the certificate has to be adjusted — and extending the scope is a separate audit.
• Second hidden item: tools bought for the sake of one control that nobody then operates. A change of process is usually cheaper than a tool, it is just harder to see in a budget.

Before you ask a certification body for a quote, have the scope and the number of people it covers decided. With those two figures you get comparable quotes; without them you get numbers that cannot be compared. Preparing the basis for the enquiry is an afternoon of work and it saves more than negotiating the price.

How long the individual routes take

For legislation, this is where the list of statutory deadlines usually goes. There are no deadlines here — standards do not impose any. Instead we give realistic durations for the individual routes. The figures for the certification cycle follow from the rules that accredited certification bodies work to; the other rows are our estimates from projects and vary mainly with the size of the scope and with what already works in the company.

Official sources

This guide is informative and does not replace the wording of any standard, framework or legislation. We deliberately do not reproduce the texts of standards and criteria — for ISO, CIS and the AICPA the licence terms do not allow it. All the figures above come from these sources, as at 8 August 2026.