QUESTIONS ON STANDARDS

First find out what they actually want. In practice, three different requirements hide behind the sentence "we want ISO" and only one of them means a certificate:

• A certificate as a condition of the contract or the tender. Nothing can substitute for it here — either you have it or you fail the condition. It is usually written into the tender documents or the framework agreement, so it can be checked.
• Evidence of the level of security. The customer wants to know how things look at your end, and the certificate is only a shortcut for them. A completed security questionnaire, a description of controls, test results or a report from an independent assessment will serve just as well.
• Transfer of responsibility. The buyer needs something in the file that justifies the choice of supplier. Here too, a demonstrable answer is often enough, provided it is specific and dated.

The practical step: ask for clarification in writing. The question "is the certificate a condition, or are you looking for evidence of specific controls?" saves you a project of several months in half the cases. If it is a condition, expect a cycle with annual surveillance audits rather than a one-off exercise — the cost breakdown is in the guide.

For improving security, yes; for evidencing it externally, only to a limited extent. CIS Controls are a catalogue of controls — they help you do the right things in the right order, but nobody issues them as evidence and you cannot certify against them.

When they are enough: you have no regulatory obligation, customers do not require a certificate and you want to reduce risk as fast as possible. The lowest Implementation Group can be worked through without external help and the result shows in operations, not in documentation.

When they are not: Act No. 264/2025 Coll. applies to you — in which case the source of requirements is the decree, not a catalogue. Or you have a certificate written into a contract. Or you sell abroad, where a certificate is effectively the price of entry.

The good news is that the work is not wasted. Controls implemented from the catalogue can later be evidenced to an auditor and to the supervisory authority — all that is missing are the formalities the catalogue does not deal with: the scope of the management system, risk assessment, records of evidence.

Working to a standard without certification is legitimate and fairly common. A standard forces nobody into an audit — certification is voluntary third-party confirmation, not a condition of working to it.

The difference lies in what you do with it externally. Without a certificate you can say "we work to ISO/IEC 27001", but you cannot back it with a stamp; some customers accept that, others do not. With a certificate you have evidence, but you pay for obtaining and maintaining it and you accept a regular audit.

What to watch out for in marketing: wording such as "we are compliant with ISO 27001" from a company without a certificate tends to be read by customers as misleading, and due diligence usually exposes it. It is cleaner to write what is actually true — a management system built to the standard, certification not yet completed.

The intermediate step companies most often choose with us: build the system to the standard, have an independent readiness assessment done, and decide about certification only when somebody genuinely requires it.

They are not competitors, they are different tools. NIST CSF describes where you stand and where you want to get to, and it does so in language management understands. ISO/IEC 27001 is the way to turn that into a management system that somebody outside verifies and confirms.

In practice they follow one another: the framework gives you the picture and the priorities, then the standard is used to implement and certify the part that has to be demonstrable. The reverse order — certification first, then the question "what do we actually want to improve" — leads to a management system that survives the audit and interests nobody in the company.

When the framework alone is enough: nobody asks you for evidence and you mainly need to decide on priorities and budget. When the standard alone is enough: the certificate is a contractual condition and there is no room for a debate about the target state. Both at once make sense for companies growing into regulated territory that want one structure the decrees can also be hung on.

The choice of framework does not follow the size of the company but what you need to evidence. Size affects the effort, not the direction — which is just as well, because otherwise small companies would end up with no structure at all.

For ten people the order usually works out like this. First the operational baseline: backups that are tested, updates, account management and multi-factor authentication, an inventory of devices. Then the lowest CIS Controls Implementation Group as a completeness check. Only when a customer requirement or regulation arrives do you deal with evidencing and possibly certification.

What we do not recommend in small companies: starting by writing policies. Ten pages of documentation on top of an unbacked-up server is worse than nothing — it creates the feeling that the job is done. If the act does not apply to you, we have the practical minimum written up on the page We are outside regulation, what next.

We deliberately do not quote a figure — for companies of comparable size the quotes differ by a factor of two, and a number without a scope is useless. It is more useful to know what the price consists of and what moves it.

• The certification body. The main input is 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 set by ISO/IEC 27006-1 — which is why quotes from established bodies usually differ less than companies expect.
• Preparation. Internal time from people doing this alongside their day job, plus external support where needed. This item tends to be the largest and the hardest to see in a budget.
• Maintenance. Surveillance audits in the intervening years, recertification before the end of the three-year cycle, an annual internal audit and a management review. Budget for the first year only and you have budgeted roughly half.
• Tools. Optional. Before buying, it is worth checking whether a change of process solves the problem — a tool nobody operates is both a cost and an audit finding.

Before you ask for quotes, have the scope and the number of people in it decided. With those two figures you get numbers that can be compared.

In our experience nine to eighteen months from zero and six to nine months where a management system already runs because of regulation or group rules. The spread comes from the size of the scope, the number of sites and whether somebody owns the management system full time or alongside other work.

It cannot be shortened with money alone, though, and that is down to one item: the system has to run for some time in order to leave records behind. Stage two of the audit assesses how it works in operation, which assumes a completed internal audit, a management review and records from normal running. Realistically that is at least three months of live operation, usually more.

The audit itself has two stages: assessment of readiness and documentation, then the audit in operation. There is usually room between them to remediate findings. Once the certificate is issued, a three-year cycle with surveillance audits runs — an overview of how long the individual routes take is in the timeline in the guide.

Annex A is the list of security controls from which you select when implementing a management system, based on the result of the risk assessment. In the 2022 edition it contains 93 controls in four themes — organisational, people, physical and technological. Guidance on implementing them is in the separate standard ISO/IEC 27002.

The impression that it "keeps changing" has two sources. The first is the transition from the 2013 edition to the 2022 one: controls were regrouped and some were merged, so the numbering and the structure changed even though most requirements stayed the same in substance. Certificates under the older edition could only be used for a transition period, which ended on 31 October 2025 — the transition rules were set by document IAF MD 26.

The second source is the 2024 amendment to the standard, which added consideration of climate-related issues. That one touched the opening clauses on the context of the organisation and interested parties, not Annex A — it added no new control.

In practice: if you are certified, the transition is behind you. If you are only starting, you work with the 2022 edition and the climate amendment from the outset and there is nothing to rewrite.

Yes, budget for it. The text of ISO/IEC 27001 is protected by copyright and is sold; in practice ISO/IEC 27002 is bought as well, because without it the Annex A controls are implemented by guesswork. Copies circulating on the internet or on internal shared drives are a breach of the licence and the auditor will notice.

For the Czech market you do not have to buy from ISO, though. Both standards were published in Czech as ČSN EN ISO/IEC 27001 (issued October 2023) and ČSN EN ISO/IEC 27002 (in Czech since April 2023); they were published by the Czech Standardization Agency and are sold in its e-shop or through the ČSN online service. The electronic version costs in the order of hundreds of crowns per standard — a negligible item against the rest of the project. The Czech standard adopts the international text, so you are not buying a different document, only one in Czech.

Before you buy, check the seller's terms for how many seats you need, so that you do not end up with the standard on one person's disk and the rest of the team working from their notes.

What you do not have to buy: the frameworks and catalogues you use as a supplement. NIST CSF is freely available, the wording of CIS Controls is obtained by filling in a form, and the act and the decrees are free of charge in the e-Sbírka. That is also one of the reasons why we start there with smaller companies.

ISO does not issue certificates. They are issued by a certification body, and a certificate is worth something if the body is accredited for that standard — in the Czech Republic accreditation is granted by the Czech Accreditation Institute, in other countries by their national accreditation body.

When verifying somebody else's certificate, look at four things:

• Scope. What exactly is certified — the whole company, one division, one site, one service. A scope that does not cover what you buy from the supplier is information of no use to you.
• Validity and cycle. The issue date and the expiry date; with a three-year cycle, also whether the surveillance audits took place.
• Accreditation of the certification body. A non-accredited certificate is paper with no system of oversight behind it. The list of accredited bodies is public.
• Edition of the standard. Certificates under the 2013 edition ceased to be valid at the end of October 2025.

Verification takes a few minutes and tends to be the cheapest part of supplier assessment. For key suppliers, add the question of what exactly within the scope covers the service they provide to you.

The Statement of Applicability (in practice, the SoA) is the document that records, for each Annex A control, whether it applies, why, and how it is implemented. It comes out of the risk assessment and it is the link between what you are worried about and what you did about it.

The auditor starts with it because it quickly reveals whether the system came out of thinking or out of copying a template. Two variants attract attention: every control applied without distinction, or, conversely, controls excluded that obviously relate to your environment, with no justification given.

Practical advice: write the SoA after the risk assessment, not before it, and keep it as a living document. If the environment changes during the year — a new service, a new supplier, a different way of working — and the SoA stays untouched, that is a finding that will surface at the surveillance audit.

Yes, and it is common. The organisation sets the scope and it can be defined organisationally (a division, a subsidiary), geographically (a site) or by service. The scope is stated on the certificate and it is the first thing an informed customer reads on somebody else's certificate.

The catch: the scope has to be defensible. Excluding processes the certified service rests on — development, infrastructure operations or identity management, say — is hard to sustain, because the dependencies show up in the audit. The second catch is commercial: a scope that does not cover what the customer is asking about will not help them approve you as a supplier, and you will have paid for a certificate that fails its purpose.

And a third one, which shows up later: extending the scope is a separate audit. When the company grows or changes structure, budget for it as a separate item. That is why we treat the scope as the first decision of the project, not as a formality before signing with a certification body.

No. CIS Controls are a catalogue of controls, not a certification scheme. There is no accredited body issuing a certificate of conformity, and the phrase "we are CIS certified" is factually wrong.

What is done instead: a self-assessment or an independent assessment against the catalogue, resulting in a report — which Safeguards are implemented, which partially and which not at all. The report can be sent to a customer as evidence of your state, but it does not carry the weight of a certificate; it is our claim or yours, not confirmation by an accredited body.

For plenty of companies that is still enough — mainly where the customer wants to see specific controls rather than a stamp. If you need evidence with third-party weight, the route runs through ISO/IEC 27001.

They are the three Implementation Groups the catalogue is divided into, according to how many resources an organisation has and how sensitive the data it handles is. The groups are cumulative — IG2 includes IG1, IG3 includes IG2.

• IG1 — basic hygiene, 56 Safeguards. The typical addressee is a small or mid-sized organisation without a security team of its own, protecting mainly employee and financial data and unable to absorb long outages.
• IG2 — for organisations that already have somebody dedicated to security and handle customer data or several operating environments.
• IG3 — the whole catalogue, 153 Safeguards. It assumes in-house specialists and data whose compromise has an impact beyond the company.

Placing yourself in a group is not an administrative act and is not registered anywhere. In practice it is recommended to start with IG1 regardless of where the company sits — the higher groups build on it. And if while reading you think IG1 is below your level, walk through it in your own environment: most often companies get stuck straight away on the inventory of what they actually have on the network.

The group descriptions above are our own wording, 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.

Carefully — and read the licence. CIS Controls are published under the Creative Commons Attribution-NonCommercial-No Derivatives 4.0 International licence. It follows that distribution is allowed for non-commercial purposes and with attribution, that modified versions must not be distributed, and that commercial use is subject to prior consent from the Center for Internet Security.

Internal use inside your company is covered by the licence. Where it breaks down is publishing and selling: the text of Safeguards copied into a proposal, into product documentation or onto a commercial company's website is already a commercial context. That is why we do not give the wording of the Controls on these pages either, and describe the topics in our own words.

The safe option, which we use in projects too: reference the catalogue and the Safeguard number and describe your own control in your own words. You get the same thing — traceability — without having to deal with the licence. If you need to distribute the wording commercially, contact CIS.

The framework is not legislation and is not tied to US jurisdiction — it is a way to describe your state and your goal. It is used globally precisely because it imposes nothing on anyone.

In the Czech environment it has three practical uses. The first is communication with management: the six functions (Govern, Identify, Protect, Detect, Respond, Recover) are understandable outside IT and the difference between the current and the target profile fits on one page. The second is prioritisation — when there are too many findings, the framework provides a structure in which decisions can be made. The third is mapping: the subcategories carry references to other catalogues, so one language can also describe what you do because of a decree.

What not to expect from it: a list of specific controls or a certification. The framework says what outcome to achieve, not how. Tools and parameters you add from elsewhere — from a catalogue of controls, from a decree, or from your own risk assessment.

It was never binding — it was created in 2020 as non-binding guidance for organisations outside the scope of the Cybersecurity Act. 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.

As at 8 August 2026 it also holds that the document is not listed among the NÚKIB supporting materials and we were unable to download the original file from the authority's website, while other materials from the same location download without trouble. The links to "MBS v1.2" circulating on the internet therefore point to a historical document. Its content has not aged dramatically, but it cannot be cited as current guidance from the authority.

What comes closest today: the NÚKIB 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), which explains Decree No. 410/2025 Coll. through examples. It is written for regulated entities, but nothing prevents using it voluntarily as guidance. For companies outside regulation we additionally recommend the lowest CIS Controls Implementation Group and our recommended minimum.

That they want a report, not a certificate. SOC 2 is an attestation engagement under the standards of the US institute of accountants, the AICPA: an independent audit firm assesses the controls with which you deliver your service and issues a report with its own opinion. No certificate is issued and there is no register to look in — the evidence is that report and nothing else.

The scope is made up of five areas known as the Trust Services Criteria: security, availability, processing integrity, confidentiality and privacy. Security is mandatory, the rest the organisation chooses according to what it promises with the service. That is why two SOC 2 reports need not cover the same ground, and the first question is always which criteria are in scope.

The practical consequences for you. It is months of work rather than weeks, because the type customers care about evaluates how things worked over a past period. It is a recurring matter — the report covers the past and next year the customer will want a new one. And it pays to ask the same question as with ISO: is the report a condition of the contract, or is the customer after evidence of specific controls? In Europe, SOC 2 shows up mainly with suppliers of cloud and software services for US buyers; Czech cybersecurity legislation does not list it as evidence of compliance.

In what the auditor assesses and over how long a period.

• Type I assesses the description of the system and whether the controls are designed so as to meet the chosen criteria — and that as at one point in time, typically the date at the end of preparation.
• Type II additionally assesses operating effectiveness over a period. The auditor tests the controls and the test results are stated in the report. The period tends to be six to twelve months.

For the buyer the difference matters: Type I says "this is how it was designed", Type II says "this is how it worked". Type I is therefore treated as an interim step — it can be issued sooner and shows that you are on the way, but an experienced buyer will ask about Type II within a year.

When you are the one asking for a report, ask straight away for type II and for the period it covers. A report for a period that ended a year ago says nothing about today. In practice the gap between the end of the period and today is bridged by a so-called bridge letter — but that is a statement by the supplier's management, not an auditor's opinion, and it carries the corresponding weight.

No. They differ in subject matter, in who does the assessment and in what comes out of it.

• Subject matter. ISO/IEC 27001 assesses the information security management system, that is, the mechanism that selects, implements and reviews controls. SOC 2 assesses the controls relating to a specific service and to the chosen criteria.
• Who. An ISO certificate is issued by an accredited certification body. A SOC 2 report is issued by an audit firm under AICPA attestation standards; accreditation in the sense the ISO world knows it does not exist here.
• Output. With ISO it is a one-page certificate with the scope stated. With SOC 2 it is a report of dozens of pages — the description of the system, management's assertion, the auditor's opinion and, for type II, the list of tests and their results.
• Distribution. An ISO certificate can go on your website. A SOC 2 report is intended for a defined group of recipients and is sent under an NDA. For public use there is the shortened counterpart SOC 3, which rests on the same engagement but contains neither the detail nor the test results.

Companies selling into both Europe and the United States do both. The work overlaps to a large extent — one risk assessment, one register of controls, one register of evidence serve both — but there are two engagements, each runs separately and each is paid for. If only European customers are involved, adding SOC 2 to certification usually makes no sense; if only US ones, it tends to be the other way round.

Before you open it, one formality: the report is intended for a defined group of recipients, so an NDA almost certainly comes with it and it goes no further. Inside, four things at the beginning and two at the end are enough.

• Type and period. Type I, or Type II? For type II, what period the report covers and how long ago it ended. Freshness matters as much as content here.
• Scope of the system. Which specific services, environments and locations are described. A report on a different product from the one you buy tells you nothing.
• Chosen criteria. Security is always there. Whether availability, confidentiality or privacy are also in scope depends on what the supplier promised — if you require guaranteed availability from them and the report does not cover availability, they have not evidenced it.
• The auditor's opinion. Is it unqualified? A qualified or adverse opinion is in the opening part and is read first, not as a footnote.

At the end of the report there is a section with the tests and their results. Look at the exceptions: which control failed a test, how many cases it involved and what the supplier added about it. A report with no exceptions at all for an extensive service is not a sign of perfection but a reason to look again at how narrow the scope was.

And the thing almost everybody skips: the other information usually lists the controls you have to provide on your side for the supplier's controls to work at all — typically management of your accounts and permissions, configuration of the service, your own backups. It is the only place where the report explicitly says what remains your responsibility, and in an incident both sides will come back to it.

Not automatically. Certification is a strong foundation, but it is not evidence of compliance with Decree No. 409/2025 Coll. and no Czech legislation lists it as proof of conformity. The standard requires a working management system and a risk-based selection of controls; the decree requires specific things and evidence of them for the supervisory authority.

What certification does cover: risk assessment, asset and supplier inventories, access and change management, continuity, documentation, internal audit and management review. That is a substantial part of the work and it makes entry into the higher regime considerably easier.

What you still have to do: registration with NÚKIB, incident reporting within the deadlines and by the prescribed route, the specific parameters of technical controls under the decree, and the cybersecurity audit under Section 16 of Decree No. 409/2025 Coll., which has a different scope and different qualification requirements from a certification audit. It is covered in more detail in our Cybersecurity Act FAQ.

No, and this direction is the worse one in practice. A company that built its security purely to the decree usually has controls in place but lacks what a certification auditor assesses first: a coherent risk assessment across the scope, a Statement of Applicability, an internal audit of the management system and a documented management review.

The difference lies in the subject of the assessment. The supervisory authority asks whether you meet the specific requirements of the legislation. The certification auditor asks whether the system that selects, implements and reviews those controls works. Meeting the first without the second is possible; the other way round is harder.

If you know you will need certification, it is cheaper to build the management system so that it serves both from the start — one risk assessment, one register of controls, one register of evidence, and from that you pull whatever somebody happens to want to see.

It helps as a foundation, but for neither of them is it enough.

Under the CRA, what is assessed are the properties of the product and the evidence of how they came about. A management system covers the process part — change management, vulnerability management, suppliers — but it replaces neither product-level risk assessment, nor the software bill of materials, nor setting the support period, nor the technical documentation. A certificate also does not create a presumption of conformity; only a harmonised standard cited in the Official Journal does that.

With DORA the situation is similar: the ICT risk management framework overlaps with an ISMS to a large extent, but the register of information, the classification and reporting of incidents within deadlines and the contractual provisions towards providers do not fall out of the standard.

A useful rule: certification shortens the route but does not satisfy the addressee. If you have an obligation under a regulation, the regulation leads and the standard is used as the structure it is built on.

No. Certification covers one part of the regulation and leaves the rest open — and the open part is the one that gets companies into trouble in practice.

What helps. Article 32 of Regulation (EU) 2016/679 requires security of processing appropriate to the risk, and that is exactly the question an ISO/IEC 27001 management system deals with: risk assessment, access management, encryption, continuity, testing of controls, work with suppliers. On top of that you have evidence that somebody outside reviewed it.

What it does not cover. Legal bases and lawfulness of processing, information duties towards people, records of processing activities, handling data subject requests, impact assessments, processor contracts, transfers to third countries, notifying a personal data breach to the supervisory authority within 72 hours, and a data protection officer if you have to have one. The standard says nothing about any of that, because these are legal questions, not security ones.

Formally it breaks down in one more place. The regulation does recognise certification in Article 42 as a tool for demonstrating compliance, but it has to be a mechanism approved by the supervisory authority. An ISO/IEC 27001 certificate is not such a mechanism, and as at 8 August 2026 the Office for Personal Data Protection states that accreditation for issuing certification under the regulation cannot yet be applied for — so no approved GDPR certification exists in the Czech Republic. Anyone offering you one is selling something other than what they claim.

In practice: treat the standard as the basis for the security part and deal with personal data protection alongside it, legally. There is also a standard for a privacy information management system, ISO/IEC 27701, which helps with structure and with the division of roles between controller and processor — the second edition of 14 October 2025 turned it into a standalone standard, whereas previously it built on ISO/IEC 27001. Even that, though, is not certification under Article 42 and it does not replace legal assessment.

Most questionnaires can be answered without a certificate, provided your answers are specific and demonstrable. What works:

• A description of the control relevant to the question — how it is set up at your end, what enforces it and who owns it. A general "yes, we have that" invites another round of questions.
• A dated output of an independent assessment — a report from an audit, a maturity assessment or a test. It does not have to be free of findings; what matters more is that it exists and that it shows what happened to the findings.
• Test results for the parts that concern the customer — typically the application or the interface you provide to them.
• A plan for what you do not have yet. A date and an accountable role are a better answer than silence or a promise that you are "working on it".

What not to do: fill the questionnaire in optimistically. The answers tend to become an annex to the contract and somebody will come back to them during an incident. Recurring questionnaires can be handled with one well-prepared set of answers — and if dozens arrive a year, that volume is usually the reason certification eventually pays off.

The source of duplication is almost never the impossibility of sharing, but the organisation of the work — one person owns the standard, another owns the decree and each keeps their own spreadsheet. Ask how many controls the company has and you get two different numbers.

What works:

• One register of controls. There is one control and there can be several addressees — the standard, the decree, a customer questionnaire, an insurer. The addressee is a property of the control, not a reason for a new one.
• One register of evidence. A record of a restore test evidences a requirement of the standard and of the decree alike. Store it twice in two places and it is only a matter of time before the two diverge.
• One risk assessment. Different methodologies for the standard and for the legislation are unnecessary; it is enough that the output can serve both.
• A decision on which one leads. Where the obligation is statutory, the legislation leads — it has a deadline and a penalty. Certification is built on top of that.

This is how we set it up in projects where several requirements meet at once; the result is not less work on security, but considerably less work on evidencing it.

Spreadsheets work until the registers drift apart — which tends to happen in the second year. That is why we built our own GRC platform, Observa: one set of records for assets, risks, suppliers, policies and incidents, from which the state is projected into every framework that shares the same controls. The trial period is seven days free, no payment card and no commitment, in limited scope; pricing starts at CZK 2 990 per month.