Practical guides on EU cybersecurity regulations and compliance requirements for companies operating in Poland and the European Union. We explain NIS2, the Polish KSC Act, DORA, the Cyber Resilience Act, ISO/IEC 27001, NIST Cybersecurity Framework and related obligations in a clear, business-focused way.
NIS2 Assessment or Readiness? Scope, Costs and Delivery
Does your organization need a NIS2 readiness assessment or help implementing the required changes? This guide compares two service models: NIS2 Diagnoza, focused on assessment, and NIS2 Gotowość, covering readiness and implementation. It explains the process from kick-off and document review to reporting and delivery, together with indicative costs, timelines and conditions to agree before starting. An incident-procedure example illustrates the difference between identifying a gap and verifying that it has been resolved.
Prepared by: CCyber Editorial Team
NIS2 Diagnoza identifies the organization’s gaps and required actions. NIS2 Gotowość extends the work to agreed implementation activities. The appropriate choice depends primarily on whether the organization understands its current position and can deliver improvements itself.
Both models should start with an agreed scope, responsibilities and verification criteria. An assessment should not end with generic observations, while implementation should not be considered complete merely because documents have been prepared.
The practical distinction is straightforward: an assessment establishes what needs to change. Completed and verified implementation demonstrates what has improved.
20 September 2026
The service names, four process stages and indicative price and duration ranges come from the service-model description supplied for this article. They are not market-rate research or a binding quotation for every organization. The proposed deliverables, acceptance criteria and scenario below are CCyber recommendations to be agreed in the engagement.
Business owners, boards, IT managers and people coordinating preparation for NIS2 and Poland’s National Cybersecurity System Act, known as KSC. It is particularly relevant to organizations comparing advisory proposals, working with existing documentation or seeking help implementing earlier recommendations.
Before assessing the organization’s current state, establish the applicable requirements. For a Polish organization, this involves its activities, KSC applicability criteria, entity status and relevant special provisions. This approach is reflected in the Ministry of Digital Affairs guidance on essential and important entities.
Applicability analysis and gap assessment are different tasks. The first determines which duties apply. The second compares the current state with those requirements. A proposal should specify whether applicability analysis is included or whether the engagement relies on an existing assessment.
The NIS2 applicability guide in the Cybersecurity for SMEs category provides further background.
The purpose is to understand the organization and agree how the engagement will operate. Discuss services, important systems, providers, existing documentation and the intended outcome. Establish who can supply information and approve decisions.
Proposed output: confirmed scope, an information request, contacts and a schedule. A one-hour meeting does not replace detailed applicability analysis or examination of the entire environment.
In the process description, assessment is the evaluation stage. Materials are compared with the agreed requirements, and declarations are checked against available information about systems and operational processes.
Proposed scope to agree: review policies, registers, reports and selected configurations, then clarify discrepancies with responsible personnel. The result should distinguish verified information, missing implementation and areas that could not be checked.
The 3-5-day range does not promise complete testing of every application and location. Assessment does not automatically include penetration testing, active scanning or production changes. Such activities require separately agreed scope and safety arrangements.
The report should help determine what to improve, why it matters and which actions take priority. “Improve access security” is inadequate without identifying the affected system, the problem and the intended result.
Proposed output: a management summary, justified findings and an action plan. Each action should identify an owner, dependencies, a deadline and a verification method. Establish which conclusions require further investigation.
Following the assessment, the organization can implement actions internally or agree further support. In this model, the broader implementation stage corresponds to NIS2 Gotowość.
The objective goes beyond supplying another set of recommendations. Scope should distinguish policy development, configuration, coordination and outcome verification. Each party needs to understand what the consultant delivers, what requires an administrator and what depends on management approval.
Proposed output: implemented and verified actions within the agreed scope, followed by operational handover. Activities outside the engagement should be identified rather than hidden behind an overall “ready” status.
Model scope: NIS2 readiness assessment and identification of gaps, risks and required actions.
Indicative budget: PLN 10,000-20,000.
Duration range: 5-30 days.
This model addresses the need: “We do not know where we stand or how much work remains.” It can support decisions about budgets, responsibilities and commissioning specific improvements.
It is also worth considering where documentation exists but has not been checked against actual operations. The objective should not be to rewrite everything automatically, but to establish which materials remain useful and what is missing.
Boundary: identifying a gap does not fix it. The report can support programme planning, but does not activate safeguards or independently establish full compliance.
Model scope: preparing the organization for NIS2 requirements through practical recommendations, an action roadmap and agreed implementation.
Indicative budget: PLN 15,000-40,000.
Duration range: 1-12 months.
This model addresses the need: “We understand some of our gaps but need help resolving them and coordinating delivery.” The roadmap should establish the sequence of work and its dependencies.
An agreed scope might include updating procedures, implementing access arrangements or preparing and testing incident handling. Specific activities, system coverage and delivery responsibilities must be defined in the proposal.
“Gotowość”, meaning readiness, describes the engagement’s objective, not an unconditional guarantee of a favourable inspection outcome. Identify which requirements the project covers and which evidence supports the assessment. Purchasing the package does not automatically fulfil every organizational obligation.
The process description gives 3-5 days for analysis, while the Diagnoza model gives 5-30 days. It does not specify whether these are working days, calendar days or team effort. They should neither be treated as equivalent nor added together without clarification.
Agree in the proposal: the event that starts the schedule, expected report date, time for providing information and arrangements for reviewing findings. Separating analytical effort from elapsed project time is useful, but must be confirmed in the delivery plan.
The supplied model does not specify VAT treatment. The PLN 10,000-20,000 and PLN 15,000-40,000 figures should therefore be treated as indicative ranges requiring clarification. An individual proposal should state the price, VAT and billing method explicitly.
Nor is it confirmed whether the Diagnoza fee is included in Gotowość, credited towards it or billed separately. Do not automatically add the figures or assume a combined discount.
Before commissioning, establish whether the quotation covers licences, hardware, work by the existing IT provider, testing, travel and subsequent operation. The stated ranges do not settle those questions.
A 1-12-month duration does not mean unlimited team availability for the same price. The proposal should define activities, availability, acceptance and change approval. A larger scope may require a different quotation.
For organizations meeting the criteria when the amendment entered into force on 3 April 2026, the relevant transition period provides for implementation by 3 April 2027. Entities required to self-register must also meet the 3 October 2026 deadline. Details are provided in the official Ministry of Digital Affairs timetable.
A twelve-month project starting in autumn 2026 cannot assume that activities required by April 2027 will be delivered only at its conclusion. Similarly, waiting for an assessment report does not justify missing an earlier registration deadline.
CCyber recommendation: distinguish actions required before the applicable deadline from subsequent operation and improvement. Organizations following another route or meeting the criteria later need a separately established schedule.
Appoint one coordinator to collect information and route questions to the appropriate people. That person does not need to know every configuration, but should know who can verify it and who approves decisions.
Prepare initially: a business and critical-service overview, system and supplier lists, existing policies, the risk register and earlier review results. Mark unavailable material as missing. Do not create misleading evidence merely to complete an information request.
Technical questions can be supported by current reports or controlled demonstrations of configurations. Direct access, site visits and tests should follow the agreed needs and scope. Being able to hold an online meeting does not establish that every assessment can be completed entirely remotely.
Agree a secure repository, authorized recipients and access termination arrangements. Do not send passwords, private keys or complete customer databases as ordinary attachments for an introductory discussion.
We recommend a report identifying scope, assessment date, requirement sources, verified findings, unassessed areas and actions. Every significant gap should describe the consequence and a proposed response.
Do not confuse missing evidence with evidence that a safeguard is absent. Where a configuration was unavailable, the appropriate conclusion may be “unverified”, not automatically “met” or “not met”.
Agree which materials will demonstrate completion: an approved procedure, configuration, test result or operating record. When the project ends, the organization should know who maintains the safeguard and when it needs checking again.
Evidence examples and mappings are available in ENISA’s NIS2 Technical Implementation Guidance. It supports implementation of Regulation 2024/2690 for specified entities. It is not automatically a complete checklist for every organization covered by KSC.
Distinguish “planned”, “implemented” and “verified”. For remaining gaps, identify the next decision, owner and deadline. Completing 90% of project tasks does not independently establish 90% statutory compliance, particularly where the remaining gap affects an important service.
Illustrative CCyber scenario. A services company has an incident-response document naming its administrator. However, no deputy or alternative contact method has been agreed for a business-email outage.
During Diagnoza, the team records the gap, its scope and the possible consequence: delayed response. It recommends assigning a deputy, agreeing communication and verifying the process. The problem has been identified, but not yet resolved.
During Gotowość, the organization and provider deliver the agreed changes. Management approves responsibilities, the provider confirms availability and the procedure is updated. An announced exercise follows, without sending a fictional incident through an authority’s production reporting channel.
Acceptance criterion: the right person receives the report, understands their role and starts the agreed actions within the established time. The result covers the tested scenario, not every possible incident.
Exercise preparation is explored in the Incident Response and Business Continuity category.
A consultant can assess, recommend and deliver agreed activities. The organization must still make decisions, ensure relevant personnel participate and maintain the resulting processes.
Outsourcing the work does not remove management’s statutory accountability. Articles 8c-8d of KSC address responsibility where duties are entrusted to others, together with decisions, resources and oversight.
Identify the implementer, approver and operational owner separately. Do not assign every action to the consultant when delivery depends on a system provider or a business decision.
The EU Cyber Regulations and Compliance category explores obligations and evidence in greater detail. This article supports selection of an engagement scope and delivery arrangements rather than repeating the entire NIS2 checklist. The linked CCyber blog resources are in Polish.
The CCyber NIS2 compliance programme covers gap analysis, maturity assessment, action planning and support with implementing policies, procedures and controls. An engagement can focus on understanding the current state or delivering agreed improvements.
Choose the outcome you need: an assessment or implementation support. Prepare a description of the business, important systems, current progress and the applicable deadline. This supports agreement on scope, time calculations, the full price and acceptance arrangements before the project starts.
Not automatically. An audit under Article 15 has specified assessor and independence conditions. A readiness assessment or implementation engagement does not become that audit merely by changing its name. The proposal should identify the type of assessment explicitly.
Implementation support is optional in the described model. Agree the report format and recommendation detail so that the internal team or another provider can translate findings into tasks.
Do not assume so. First check the scope, current requirements, evidence quality and environmental changes. Earlier work may be reusable, but should not be treated as current solely because of the document date.
There is no basis for an unconditional promise. The engagement can define outcomes, acceptance criteria and evidence for an agreed scope. The authority assesses applicable obligations and the organization’s actual position, not simply whether it purchased a package.
Agree prompt escalation and identify the decision-maker. A significant threat or suspected incident should not wait for the final report. Technical action still requires impact assessment and appropriate authorization.
NIS2 Diagnoza supports decisions based on identified gaps. NIS2 Gotowość adds delivery of agreed improvements. The four-stage process connects understanding the organization with reporting and optional implementation.
Compare proposals through scope, responsibility and outcomes, not price or elapsed days alone. A well-defined engagement shows what was checked, what improved and which activities remain with the organization.
What Do Regulators Expect? Cybersecurity Controls and Documentation
ISMS, risk management, IAM, cryptographic keys, penetration testing, disaster recovery, business continuity, SOC monitoring and incident response: how do these areas form one programme? This guide explains how to prepare for regulatory assessment, distinguish legal requirements from implementation choices and organize the supporting documentation. It covers risk registers, RACI, control matrices and technical reports. An encrypted-database recovery example shows why separate policies cannot replace testing the complete service.
Prepared by: CCyber Editorial Team
Preparing for regulatory assessment means demonstrating that the organization understands its applicable obligations, manages risk and performs the required activities. Documentation should explain the rules and show that they have been followed. A list of purchased tools or a folder of signed policies is insufficient.
ISMS, IAM, key management, testing, recovery and monitoring need to connect with specific services and responsibilities. However, not every institution needs an identical SOC, the same penetration test or the same number of documents.
Establish the requirement first. Then define implementation and evidence that genuinely demonstrates the outcome.
20 September 2026
This article develops the supplied notes, retaining their ten security areas and documentation topic. The notes do not identify a specific regulator, jurisdiction or type of exchange. NIS2, Poland’s KSC and DORA examples are additional context supported by official sources, not an assertion that every reader is subject to all these regimes.
The review questions, evidence examples and documentation model are CCyber recommendations. They are not an official checklist or a complete catalogue of obligations.
Boards, institutional leaders, CISOs, IT teams, compliance professionals and auditors. It is particularly relevant to organizations preparing a regulatory programme, licensing application, inspection or internal review, and to buyers commissioning security documentation and services.
The statement “the regulator expects” needs an identifiable basis. Requirements may arise from legislation, authorization conditions, supervisory decisions or applicable guidance. Customer commitments and voluntarily adopted standards are separate sources.
NIS2 requires appropriate and proportionate risk-management measures. In Poland, the applicable duties must be established under KSC. DORA concerns specified financial entities and contains special arrangements and exclusions. Do not apply every requirement together without assessing scope.
The word “exchange” alone does not establish the regulatory regime. Identify the legal entity, its services, authorization basis and jurisdiction. Capital-market infrastructure should not be equated with every exchange or trading platform.
Prepare a register linking entity, service, obligation, source, deadline and owner. This helps avoid both missing requirements and commissioning work whose purpose nobody can explain.
ISMS means Information Security Management System. ISO/IEC 27001 addresses establishing, implementing, maintaining and improving that system. It includes people, processes and technology, not merely a document called “Security Policy”. Its scope is explained by ISO.
Implementing an ISMS is also identified among the obligations of relevant KSC entities. This should not automatically be equated with a requirement to obtain ISO certification.
Review: system scope, management accountability, objectives, reviews and remediation arrangements. Proposed evidence includes approved rules, decisions and operating records rather than an implementation declaration alone.
Article 21 of NIS2 connects safeguards with risk, operational scale and potential incident consequences. It does not reduce assessment to a vulnerability count or the purchase of a particular product. See the NIS2 Directive.
Review: does the risk describe a possible event and its service consequences, have an owner and lead to a treatment decision? “No MFA” identifies a gap. It does not yet explain which permissions could be compromised or what that means for the organization.
In the proposed register, connect the scenario with an action, deadline and assessment of the risk remaining after safeguards are applied. Risk acceptance should not be used as a substitute for meeting a legal duty.
IAM means identity and access management. For entities subject to the relevant DORA requirements, Articles 20-21 of Delegated Regulation 2024/1774 specify identity and access arrangements, including account lifecycles. This is a regulatory example, not a requirement to purchase a product labelled IAM.
Review: who approves access, how are role changes and departures handled, and does coverage include administrators, suppliers and application accounts?
Proposed evidence connects the request, decision, configuration and verification of access removal. An active-account report alone does not establish that every account is necessary. Further guidance is available in the Identity, Access and Cloud Security category.
“The data is encrypted” does not describe key management. Articles 6-7 of Regulation 2024/1774 address cryptography and key lifecycles within the applicable DORA scope, from creation and storage to renewal, revocation and destruction.
Review: who can use a key, how would loss or unauthorized use be identified, and how would the ability to decrypt information be recovered after a failure?
Proposed evidence includes assigned ownership, access configuration and controlled test results. Audit documentation should identify protected material and its location, not disclose private-key values or passwords.
Penetration testing, compliance auditing and vulnerability scanning are different activities. Under DORA, penetration testing is one testing method. Advanced threat-led penetration testing, or TLPT, applies to designated entities. The scope is established in DORA Articles 24-26.
Review: does the test cover the relevant service, is its scope authorized and do findings lead to remediation and verification?
The proposed evidence package includes test scope, findings, treatment decisions and retest results. A penetration-testing invoice does not demonstrate that vulnerabilities were fixed. Testing that could disrupt production needs separate authorization and safeguards.
Disaster recovery, or DR, concerns restoring technical capabilities after a major disruption. Its relationship with broader contingency planning is explained in NIST SP 800-34 Rev. 1. This is technical guidance, not a universal Polish legal requirement.
Review: does the plan include applications, information, configurations, identities, keys and supplier dependencies? Agree recovery-time requirements and acceptable loss of data currency.
Proposed evidence is restoration in an agreed environment with confirmation that the result is usable. Successful completion of a backup job is not that test.
Business continuity asks a broader question: how will the organization maintain necessary functions during disruption? NIST discusses alternate locations, equipment and temporary operating methods in its contingency-planning resources.
Review: service priorities, people, deputies, communications and acceptable operating limitations. Where appropriate, the plan should also define conditions for safely suspending a service.
Proposed evidence is an exercise involving the process owner. Do not treat a running server as proof of continuity when users still cannot serve customers or complete a required operation.
A Security Operations Centre, or SOC, is a way of organizing security operations. The supplied notes do not identify a legal basis requiring every company to operate its own centre.
For example, Annex point 3.2 of Regulation 2024/2690 requires monitoring, logging and appropriate response from entities within its scope. Its detailed requirements should not be generalized to every organization.
Review: log sources, system coverage, service hours, escalation and authority to act. Internal teams and external services both need explicit responsibilities. Proposed evidence is a controlled test from event to response, not merely an alert-volume chart.
A scan provides information but does not replace vulnerability management. Patching in particular requires identification, prioritization, deployment and verification. This process is described in NIST SP 800-40 Rev. 4.
Review: can the finding be connected to a system owner and the service it supports? Are remediation deadlines, exceptions and temporary safeguards justified?
Proposed evidence links detection and change records with reassessment. A task closed by its implementer should not automatically mean that the issue no longer exists.
Incident preparation should connect with risk management, detection and recovery. This approach is described in NIST SP 800-61 Rev. 3.
Review: who assesses events, contains consequences, preserves information and makes business decisions? Separately assign external reporting obligations, including their triggers, recipients and deadlines.
Proposed evidence is the timeline of a real incident or a clearly labelled exercise. A supplier’s phone number alone does not establish readiness. Practical exercise guidance is available in the Incident Response and Business Continuity category.
The supplied notes include this range without a source, organizational description or counting method. We do not treat it as a verified industry benchmark or a legal requirement.
One count might include an overarching policy, instructions for dozens of systems, forms, annexes and local versions. Without a common definition, file counts reveal little about scope or quality.
This does not make documentation unnecessary. A required policy or procedure remains an obligation even where the technical safeguard operates. Conversely, an extensive document catalogue does not establish that its activities have been performed.
A better purchasing criterion: request a defined set of obligations, documents and outcomes rather than a “200-procedure package”.
The following structure connects security policies, risk registers, process descriptions, RACI, control matrices, operating procedures and technical reports. It is a proposed working model, not a folder structure imposed by every regulation.
These establish objectives, scope, accountability and principles. For example, an access policy identifies who approves permissions and how exceptions are handled. It does not need to contain click-by-click instructions for every application.
The risk register explains what needs managing. The process description shows the workflow, inputs, decisions, participants and output. Connect the two so that the reason for an activity is clear.
RACI distinguishes the people performing a task, the accountable owner, those consulted and those informed. The roles are explained in the official Section508.gov guidance. It is used here to explain the method, not as the basis of cybersecurity obligations.
In practice, establish who authorizes urgent access removal and who performs it. Putting “IT” in every cell does not resolve the relationship between an administrator, provider and service owner. A RACI assignment does not transfer statutory accountability.
These connect the requirement, safeguard, scope, owner, assessment method and evidence. One control can support several obligations, but only to the extent that it actually meets them.
ENISA publishes evidence examples and requirement mappings for implementing Regulation 2024/2690. The material is useful, but its scope is not a universal catalogue for every company and institution.
These explain how to perform activities such as removing access, renewing a key, restoring a service or escalating an alert. They should establish triggers, permissions, steps and completion criteria. Test them with the people expected to use them.
These show a state or result: configuration, a completed review, penetration-test findings, incident activity or recovery. Identify dates, scope, limitations and follow-up work. A report without decisions on significant findings leaves work outstanding.
We recommend linking requirement → risk → rule → procedure → execution → result → remediation.
Each document should have an owner, scope, version, approval status and review arrangements. A service change should trigger consideration of related materials, not merely a new date on the cover.
When consolidating documentation, do not remove required content in the name of brevity. Duplicates can be reduced while preserving necessary approvals, scope and the ability to reconstruct earlier decisions.
Also establish access and retention arrangements. Documentation can reveal weaknesses, suppliers and architecture. Provide it to the authority under the applicable request through a secure channel, without adding unnecessary secrets or information.
Illustrative CCyber scenario. An organization has an encryption policy, a disaster recovery plan and a report confirming a successful database backup. Each document has been approved separately.
An agreed exercise reveals that the recovery team has no available route to use the key needed for decryption. Access depends on an identity service that is also unavailable in the failure scenario. Consequently, the backup cannot support restoration within the intended time.
The organization updates dependencies, emergency permissions, key ownership and recovery instructions. It then repeats a controlled test and obtains application acceptance from the business owner. It does not solve the issue by writing the key into a broadly accessible document.
The lesson: separate confirmations of encryption, backups and IAM do not establish that the complete recovery scenario works.
Establish the basis and scope. Identify the regime, assessment stage, systems and services. A pre-launch authorization process may need different material from an evaluation of several months of operation. Do not present planned implementation as completed work.
Select an end-to-end scenario. Follow one important service through access, keys, monitoring, incidents and recovery. This does not replace the full required assessment scope, but can expose inconsistencies.
Assess documentation and operation separately. Distinguish missing rules, missing implementation, missing evidence and a failed test. These are different problems requiring different actions.
Approve remediation. Each significant gap needs an owner, deadline and reassessment method. A remediation plan records the response to a gap, but does not automatically turn non-compliance into compliance.
Detailed guidance on obligations, Statements of Applicability and evidence is available in the EU Cyber Regulations and Compliance category. This article connects the security scope with documentation rather than replacing a detailed implementation guide. The linked CCyber blog resources are in Polish.
Through its EU regulatory compliance services, CCyber supports gap assessment, policy preparation and updates, responsibility mapping, registers and audit materials.
Check whether your documentation reflects actual operations. Prepare the applicable obligations, important services and open issues to define the review. The objective should be a plan for closing specific gaps rather than increasing the file count.
That should not be inferred merely from a monitoring obligation. Check the applicable rules, coverage and response availability. An internal team or external service may form part of the solution where the relevant requirements are met.
Scope and frequency depend on applicable rules, risk and changes. DORA distinguishes a testing programme from advanced TLPT. Do not apply one schedule to every organization and system.
No. A certificate concerns a defined management-system scope. Applicable legal obligations still need assessment, including registration, notifications and sector-specific requirements.
It can provide a starting point, but must be adapted to services, roles and configurations. Before approval, check that the organization can perform the described activities and is not claiming safeguards that have not been implemented.
No. They reflect the supplied notes. A complete assessment may need other areas, such as assets, suppliers, training, physical security or software development. Additions should follow applicable requirements and risk.
Regulatory preparation connects management, technology and documentation. ISMS, risk, IAM, keys, testing, recovery, continuity, monitoring, vulnerabilities and incident response should operate as connected processes.
Do not begin with a document count. Begin with what the organization must be able to do and how it will demonstrate that capability. Documentation should support performance and verification, not replace them.
NIS2 Changes in 2026: What the EU Proposal Means for SMEs
The European Commission has proposed targeted NIS2 amendments covering technical requirements, ransomware reporting, certification, supervision and regulatory scope. This guide explains which changes could benefit SMEs, how small mid-caps differ from SMEs and why the proposal does not postpone Poland’s current KSC deadlines. It includes a business scenario and a regulatory change record to help organizations prepare for reform without prematurely stopping their compliance programme.
Prepared by: CCyber Editorial Team
The proposed NIS2 amendments could reduce some administrative burdens and change the classification of certain businesses. They are not a blanket SME exemption or a reason to postpone existing obligations.
For a Polish company, two assessments must remain separate: what Poland’s National Cybersecurity System Act, known as KSC, requires today and what a future reform could change. Leave room to update the programme, but do not remove obligations on the basis of an announcement.
The practical benefit lies in the specific mechanism, not the word “simplification”: fewer additional national requirements, a narrower sector definition or reduced duplication of audits.
20 September 2026
The starting points are the European Commission announcement of 20 January 2026 and the Global Policy Watch analysis of 23 January 2026. We retain the analysis’s six areas of change while checking details against COM(2026) 13 and EU institutional sources.
The legislative status, separate Omnibus IV developments and Polish deadlines supplement the original materials. The scenario, recommendations and change record are CCyber proposals. This article does not replace an individual applicability assessment.
SME owners and boards, IT providers, compliance professionals and companies growing beyond the SME category. It is particularly relevant to businesses already implementing KSC that want to determine whether the proposed reform should affect their scope or budget.
The package includes a proposed revision of the Cybersecurity Act, commonly called CSA2, and separate targeted amendments to NIS2. The Commission connects these with simplified compliance, certification and a stronger role for ENISA, the EU cybersecurity agency.
The Commission estimates that the simplifications would affect 28,700 companies, including 6,200 micro and small enterprises. These are EU-wide projections, not a count of Polish beneficiaries or companies automatically leaving regulatory scope. The source is the official Commission announcement.
Do not combine every announcement into one legal change. The January NIS2 proposal and CSA2 proposal are separate instruments. The proposed single-entry point for incident reporting originates in the earlier Digital Omnibus. Their relationship is explained on the Commission’s NIS2 proposal page.
COM(2026) 13 remains a legislative proposal. The checked procedure record for 2026/0012(COD) indicates that a parliamentary committee decision is awaited. The final scope may differ from the January text.
The draft provides 12 months for Member States to transpose the future directive after it enters into force. This is a proposed deadline for national lawmakers, not an additional year granted to every company from the press-release date.
Planning implication: keep current obligations separate from developments being monitored. Do not turn a potential future simplification into a present-day “not applicable” decision.
The proposal calls for regular assessment of whether further implementing acts are needed. Where the Commission establishes the relevant requirements, Member States would not be allowed to add further technical, methodological or sectoral requirements within that scope. The mechanism appears in the proposed amendment to Article 21(5) in COM(2026) 13.
Potential business effect: less duplicated work when operating across Member States. This does not make every national provision, form and obligation identical. The restriction would apply to the specified requirements and entities covered by the relevant implementing act.
CCyber recommendation: record the source of each requirement. Distinguish EU law, national law and customer commitments. This will make genuine duplication easier to identify after a change, rather than removing activities merely because their descriptions sound similar.
The proposal distinguishes information to be included in future reporting implementing acts from information supplied when requested by the relevant CSIRT or authority. The first category concerns ransomware detection, the attack vector and mitigation. The second concerns ransom demands and any payment associated with a significant incident.
This is not an automatic instruction to immediately submit every detail of every extortion attempt. The conditions in proposed Article 23(12) and (13) matter. A duty to provide information about a payment is not authorization to make that payment.
Clarification of the source article: detailed EU incident rules are not entirely a future development. Implementing Regulation 2024/2690 already addresses matters including incident significance for specified digital providers. Defining significance and harmonizing notification formats are different issues.
CCyber recommendation: organize the recording of demands, decisions and available information. Identify the authority contact and protect the relevant records. Do not replace the current reporting channel with an announced solution whose arrangements have not yet taken effect.
The proposal concerns European certification of an entity’s cybersecurity posture, not merely a product. A certificate demonstrating specified Article 21 requirements would limit additional supervisory audits of those same requirements. Member States could also require the relevant certification.
This does not mean “ISO 27001 instead of NIS2”. The applicable European scheme, certificate validity and exact requirements covered would matter. The organization remains responsible for compliance, as reflected in proposed Article 24(4)-(6).
CCyber recommendation: before budgeting for savings, establish which audit would be replaced and under what legal mechanism. Do not abandon current obligations or purchase a service advertised as a future exemption without a verified legal scope.
ENISA would support cooperation between national authorities and analysis of risks involving entities operating across borders. This direction is also described in the official proposal overview.
This does not make ENISA the sole regulator of every company or establish a universal GDPR-style one-stop-shop. Joint supervisory work does not automatically remove obligations towards the relevant national institutions.
CCyber recommendation: organize information about legal entities, services, countries of operation and system locations. A controlled, consistent dataset will be more useful than several conflicting descriptions prepared separately for each request.
The January proposal refers to Commission Recommendation 2025/1099. It covers enterprises that are not SMEs, employ fewer than 750 people and satisfy at least one of two financial ceilings: annual turnover not exceeding EUR 150 million or an annual balance sheet total not exceeding EUR 129 million.
This expands the abbreviated definition in Global Policy Watch. Employee count and turnover alone do not fully describe the category. The applicable calculation rules for partner and linked enterprises also matter.
Under the proposed model, some Annex I entities could move from essential to important status. Other classification grounds and exceptions would remain. It is incorrect to conclude that every company below 750 employees would leave NIS2 scope.
A classification change can affect supervision. It does not mean security requirements start only after an incident. The distinction between supervision of essential and important entities is established in NIS2.
CCyber recommendation: separately assess applicability, entity category and the resulting duties. “Important rather than essential” and “outside the legislation’s scope” are different conclusions.
On 9 June 2026, the Council announced a provisional small-mid-cap agreement under the separate Omnibus IV package, using fewer than 1,000 employees and ceilings of EUR 200 million turnover or EUR 172 million balance sheet total. See the Council announcement.
Do not automatically import those figures into current Polish KSC rules or the January NIS2 text. Check the specific act, final wording and application date first.
The proposal removes automatic coverage of DNS providers regardless of size. This could matter to micro and small providers, but other grounds for inclusion would still require assessment.
For chemicals, the proposed annex removes distribution from the sector description and refines the covered activities through REACH references. This is more than a change of heading. Details appear in the annex to COM(2026) 13.
The package does not only narrow scope. It also introduces or clarifies categories involving European identity wallets and submarine data-transmission infrastructure. A company assessment must therefore consider all relevant services.
The proposed Article 26(3) amendment extends the representative requirement to essential or important entities not established in the EU but offering services within it. Global Policy Watch notes that the wording’s scope would benefit from further clarification.
This does not mean a Polish company needs another representative merely because it sells services abroad. Establishment and regulatory status are central, not the existence of overseas customers alone.
CCyber recommendation: assign services to specific legal entities within an international group. Do not assume that one EU-established group company automatically settles the position of every other group entity.
The proposal describes planned guidance on supplier security information. Its purpose includes limiting unjustified burdens passed on to companies outside NIS2 scope. This direction appears in the explanatory material and recitals, not as an immediate legal right to reject every customer questionnaire.
CCyber recommendation: connect customer requirements with the service they concern. Prepare current assurance material with an explicit scope and sharing rules. Explain questions that do not apply rather than making inaccurate compliance declarations.
Do not confuse customer requirements with the company’s statutory status. The NIS2 applicability guide in the Cybersecurity for SMEs category explores that distinction.
The EU proposal does not independently change current KSC deadlines. For entities covered by the relevant transitional arrangements, self-registration is due by 3 October 2026 and implementation by 3 April 2027. Not every entity follows the self-registration route. Scope and conditions are explained in the Ministry of Digital Affairs timetable.
CCyber recommendation: do not stop work on access control, data recovery and incident handling solely because classification might change. Separate necessary safeguards from expenditure on activities whose statutory status could genuinely be affected.
Illustrative CCyber scenario. A company employs 120 people and only distributes chemicals. For this example, assume its current assessment established important-entity status solely through that activity.
After reading about the reform, management considers stopping the KSC project. Instead, the team records a conditional assessment: the proposed narrowing may matter, but the final EU text, Polish provisions and absence of another inclusion ground must be checked.
The company continues its currently required activities. It separately marks expenditure for reassessment after a legal change. It does not remove register information or tell customers that its status has ended solely on the basis of the proposal.
It also maintains necessary access and recovery safeguards. Even a future change in regulatory scope would not demonstrate that data-loss or disruption risks had disappeared.
The following template is a CCyber recommendation. It records the reform’s potential effect without confusing the present position with a forecast.
Current obligation: the specific basis, entity, scope and deadline.
Proposed change: the proposal number, provision and document version supporting the assessment.
Conditions: sector, size, role, certification scope or other criteria requiring verification.
Potential effect: which activity, cost or reporting arrangement could actually change?
Decision now: what continues, what is prepared conditionally and what must not yet be treated as settled?
Owner and reassessment: who follows the development, and which event triggers an update, such as publication of the final act or a Polish amendment?
“The EU plans simplification” is not a sufficient status entry. The announcement needs to be connected with a specific organizational decision.
Current obligations, evidence and inspection preparation are explored in the EU Cyber Regulations and Compliance category. This article concerns managing a proposed change rather than replacing a full applicability assessment or KSC implementation plan. The linked CCyber blog resources are in Polish.
The CCyber NIS2 compliance programme covers gap analysis, maturity assessment, action planning and support with policies, procedures and controls.
Identify which activities are required today and which depend on future reform. Your current applicability assessment, service scope and project schedule provide a starting point. The objective is to update specific decisions without promising exemptions from rules that remain applicable.
That does not follow from the proposal. The threshold forms part of a definition also involving non-SME status and financial data. A possible move to important-entity status is not an exemption.
This cannot be assumed from the proposal. The mechanism concerns the relevant European certification and the requirements it covers. Current duties must be assessed under applicable law.
The proposal alone provides no basis for that. A company currently required to submit an application by a specified deadline should fulfil that obligation under the relevant provisions.
No. Different changes concern different groups. A small DNS provider, chemical distributor, cross-border operator and company growing beyond SME status may each have a different position.
The checked sources do not establish a certain completion date. Follow adoption and publication, then the relevant implementing and national provisions. A legislative forecast is not a statutory performance deadline.
The Commission proposal could reduce duplicated requirements and change the position of selected businesses. It is not a signal that SMEs can abandon KSC preparation.
A sound organizational approach has two parallel tasks: perform current obligations and maintain a documented assessment of future changes. This allows the company to benefit from actual simplifications when they apply without making premature decisions.
HIPAA Compliance Checklist: 8 Steps for Companies and IT Providers
A US healthcare customer is asking about HIPAA compliance? Start by establishing your company’s role, the protected information involved and the obligations in its business associate agreement. This guide covers eight steps: HIPAA rules, accountability, risk analysis, safeguards, breach reporting, training, suppliers and ongoing evaluation. It also explains the 60-day and six-year requirements and the difference between a compliance assessment and a “HIPAA certificate”. A SaaS example shows why the review must extend beyond the main database.
Prepared by: CCyber Editorial Team
Start HIPAA preparation by establishing your company’s role, the protected health information it handles, where that information goes and who is responsible for protecting it. Then connect risk analysis, safeguards, provider agreements, training and breach handling into an operational programme.
Do not begin by shopping for a “HIPAA certificate” or copying a GDPR procedure. First establish the scope of the service and the applicable obligations. A checklist should produce implemented and verified activities, not a compliance declaration based solely on a signed agreement.
20 September 2026
The eight-step structure follows Vanta’s HIPAA compliance guide. Explanations and clarifications use materials from the US Department of Health and Human Services, HHS, and regulatory provisions available through eCFR. The service scenario and proposed evidence are CCyber recommendations.
This article addresses selected privacy and security requirements. It does not replace a legal assessment of the business or cover every applicable federal, state and European obligation.
IT companies, SaaS providers, hosting companies, analytics services and support teams working with US healthcare organizations. It also supports security, compliance and procurement teams organizing their response to customer requirements.
HIPAA is the US Health Insurance Portability and Accountability Act. Its implementing regulations apply to specified covered entities: health plans, health care clearinghouses and health care providers conducting particular electronic transactions. Not every healthcare organization meets that definition. The scope is explained by HHS.
A business associate is a defined type of service provider acting for a covered entity. The definition can also include a subcontractor of another business associate. The function performed and the creation, receipt, maintenance or transmission of PHI matter. Examples include hosting and certain IT services. See the HHS business associate guidance.
A Polish establishment is not an automatic exemption. HHS permits ePHI storage outside the United States when the applicable requirements and agreement conditions are met. Location must be considered in the risk assessment. This is addressed in the HHS cloud guidance.
The Privacy Rule governs uses and disclosures of PHI and individuals’ rights. PHI is identifiable health information protected in the relevant HIPAA context. Protection can apply to electronic, paper and oral information.
Treatment, payment and healthcare operations are important permitted purposes, but not the entire catalogue. Unlike the simplification in the source article, permitted disclosures should not all be restricted to those three purposes. The conditions are explained in the Privacy Rule summary.
The Security Rule concerns electronic PHI, or ePHI, and covers administrative, physical and technical safeguards. The Breach Notification Rule establishes duties following a breach within its scope. Their relationship is explained in the HHS Security Rule summary.
Action: map obligations to your role. A provider should not assume it may use information for any purpose merely because that purpose relates to healthcare.
The Security Rule requires an identified official responsible for developing and implementing the relevant security policies. This applies to covered entities and business associates under 45 CFR 164.308(a)(2).
Separately, 45 CFR 164.530(a) requires a covered entity to designate a privacy official and a complaints contact. Do not automatically apply that entire obligation to every provider in an identical form.
Action: identify who approves access, conducts risk analysis, communicates with the customer and makes incident decisions. The title “HIPAA Compliance Officer” alone does not establish authority or availability.
Risk analysis should cover all ePHI created, received, maintained or transmitted within the relevant activities. HHS does not prescribe one method that automatically delivers compliance. It does require a thorough examination of risks to confidentiality, integrity and availability. See its Guidance on Risk Analysis.
CCyber recommendation: trace information from receipt to deletion. Review the production database, exports, backups, logs, support tickets and test environments. Record the owner, access arrangements and required safeguards for each location.
Removing a name does not establish de-identification. HHS describes Expert Determination and Safe Harbor. The list of 18 identifier categories belongs to the Safe Harbor conditions, rather than being a simple test of whether a file contains PHI. Details appear in the de-identification guidance.
Completion evidence: a defined assessment scope, reasoned risks and remediation actions. A questionnaire without examination of actual data flows should not be the sole basis for decisions.
Technical requirements cover access control, recording and examining activity, integrity, authentication and transmission security. They are set out in 45 CFR 164.312. The Security Rule also covers backup, recovery and emergency-operation planning, together with workstation and media protection.
CCyber recommendation: connect each rule with implementation. For access, define roles and test permissions. For backups, verify recovery. For logging, establish who reviews significant activity and responds to findings.
Addressable does not mean optional. It requires assessment of whether an implementation specification is reasonable and appropriate, with the decision properly documented. This also concerns encryption under the current Security Rule model. The distinction is explained by HHS.
Do not overlook privacy operations: access requests, amendments and disclosure restrictions. Protecting a system does not authorize every use of its information.
Completion evidence: approved rules, appropriate configuration and a verification result for the defined scope. Account-management examples are available in the Identity, Access and Cloud Security category.
First assess whether the event is a breach covered by the Breach Notification Rule and involves unsecured PHI as defined by the regulations. Not every tool alert is such a breach. However, an impermissible use or disclosure requires assessment and a documented decision, not an assumption that nothing probably happened.
The rule requires notification without unreasonable delay and no later than 60 calendar days after discovery. Discovery includes what should have been known through reasonable diligence. This follows from 45 CFR 164.410.
The BAA may impose a shorter deadline. Do not wait for the entire investigation before providing initial information. The provision allows information to be supplemented as it becomes available.
Individual notices are required without unreasonable delay and within 60 days of discovery. A breach affecting more than 500 residents of one state or jurisdiction also triggers notification to appropriate media. Conditions and exceptions are explained by HHS.
For 500 or more individuals, HHS notification is made contemporaneously with individual notices. For smaller breaches, HHS reporting can occur within 60 days after the end of the year in which they were discovered. This does not defer individual notification. The distinction is set out in 45 CFR 164.408.
Action: record recipients, deadline triggers, deputies and contractual duties. Do not copy GDPR’s 72-hour period into HIPAA as a universal reporting deadline.
The Security Rule requires an awareness and training programme for the workforce, including management. The Privacy Rule requires covered entities to provide function-appropriate training, including for new personnel and after material policy changes. The provisions are 164.308(a)(5) and 164.530(b).
Vanta’s recommended annual cycle can be a practical arrangement. It should not be presented as a single universal training frequency imposed by those provisions.
CCyber recommendation: teach support staff safe attachment handling, administrators access control and patient-facing teams appropriate information disclosure. Use synthetic data for exercises. Retain the training scope, participants and knowledge-check results.
A Business Associate Agreement, or BAA, is not an ordinary NDA. It addresses permitted information use, safeguards, reporting, assistance with individuals’ rights and arrangements when the service ends. HHS provides sample contractual provisions.
Appropriate agreements are also needed within the chain of subcontractors handling PHI. A signed BAA records obligations, but does not itself demonstrate that the provider performs them.
An inability to read information does not always remove business associate status. HHS explains that a provider storing encrypted ePHI can be a business associate even without the decryption key. See the cloud guidance.
Action: review hosting, backups, helpdesk, analytics and any AI tools. Establish which actually receive PHI, which service the agreement covers and what your organization still needs to configure. Do not give every supplier an identical agreement without assessing its role.
Important clarification of the Vanta guide: the current Security Rule requires periodic technical and nontechnical evaluation, including consideration of changes. Section 164.308(a)(8) does not itself impose a general internal audit requirement of exactly once a year.
An audit at least every 12 months appears in the proposed Security Rule changes. HHS continues to distinguish the NPRM from the rule currently in effect. A proposal should not be presented as an operative requirement.
CCyber recommendation: establish recurring reviews and additional checks after changes to providers, integrations, access or incident findings. Report unresolved gaps, test outcomes and pending decisions, not only the number of policies.
Documentation required by the Security Rule must be retained for six years from creation or when it was last in effect, whichever is later. That is not retention for “up to six years”. The provision is 45 CFR 164.316.
This differs from medical-record retention. HHS explains that the Privacy Rule does not establish a general medical-record retention period. State laws are among the relevant requirements. See the HHS medical-record guidance.
CCyber recommendation: separately establish retention for policies, assessments, operational records and patient information. Do not copy one period into every system or delete data solely because six years have elapsed.
Illustrative CCyber scenario. A Polish company develops an application for a US clinic. Assume that an assessment has established its business associate status. The main database has restricted access and operates in agreed infrastructure.
A data-flow review finds that support tickets contain screenshots with patient information. They enter a separate tool omitted from the earlier assessment and subcontractor review.
The team establishes the information involved, assesses prior use and required agreements, and designs a safe attachment-handling process. It provides customer instructions and tests permissions using synthetic data. It does not prematurely delete material needed to assess a possible breach.
The lesson: a correctly configured main database does not establish protection at every processing location. The checklist should follow the complete service.
A business operating in Poland should independently assess GDPR. Processing in the context of an EU establishment’s activities can fall under GDPR regardless of where processing occurs. Its scope is explained by the European Commission.
Asset registers, tests and safeguards can be shared. However, a BAA should not automatically be treated as a substitute for a GDPR processing agreement, nor should the US notification process replace assessment under GDPR.
Relationships between requirements are explored in the EU Cyber Regulations and Compliance category. HIPAA remains US legislation within that comparison.
HHS does not recognize private Security Rule certificates as official confirmation of compliance. An external assessment can be useful, but does not remove organizational obligations or prevent a regulator from finding a violation. This is explained in the official HHS FAQ.
When a customer requests a “HIPAA certificate”, establish what assurance is actually needed: an assessment scope, testing report, BAA or questionnaire response. A badge on a website does not replace that discussion.
Implementation can draw on material about identity, access and cloud security and the regulatory compliance guides. This article focuses on organizing HIPAA preparation, not a complete assessment of every US healthcare obligation. Linked CCyber blog resources are in Polish.
Through its security assessment service, CCyber examines IT environments, data flows, configurations, policies and procedures. The output identifies gaps and prioritized actions.
Begin by defining the service and information you handle. For HIPAA-related work, distinguish technical assessment from legal applicability and contract drafting, which require counsel familiar with US law. A security review is not official HIPAA certification.
Yes, where it meets the relevant definition, such as business associate. Small size alone does not remove obligations. Assessment should address the service and handling of PHI, not just employee count.
No. The agreement must reflect the actual service, and applicable security and privacy requirements must be implemented. Absence of a signature also does not automatically mean statutory business associate status has not arisen.
It should not be interpreted that way. Check covered functions, agreements, configuration and responsibility allocation. The cloud provider does not make every decision about accounts, data and information use for its customer.
The eight stages organize the work, but are not a one-time examination. Changes to services, personnel and risks require further evaluation. A completed implementation task should lead to an agreed operating arrangement.
HIPAA preparation requires an understanding of organizational roles and PHI flows, followed by rules connected to operation. The eight stages help organize accountability, risk, safeguards, breach handling, training and suppliers.
The most useful assurance is consistency between the agreement, actual service and evidence. A general compliance declaration or certificate without a clear scope does not replace it.
ISO 27001 Annex A: 93 Controls and a Practical Statement of Applicability
ISO/IEC 27001:2022 Annex A contains 93 controls, but it is not an identical shopping list for every organization. This guide explains the four control themes, correct references for selected controls and the difference between a requirement, implementation and operating evidence. Learn how to select controls, prepare a Statement of Applicability and justify exclusions. A supplier-access example connects risk with a specific activity, ownership and verification.
Prepared by: CCyber Editorial Team
ISO/IEC 27001:2022 Annex A contains 93 controls organized into four themes: organizational, people, physical and technological. It provides a reference set for checking that necessary protection has not been overlooked. It does not replace risk assessment or the complete information security management system.
An organization should determine which controls are necessary within its ISMS scope, justify their selection and identify their implementation status. These decisions are recorded in the Statement of Applicability, or SoA. They must then be translated into operating processes and safeguards.
The important question is not “How many boxes have we checked?”. It is “Do the selected controls address our needs, and can we demonstrate that they operate?”.
19 September 2026
This article refers to ISO/IEC 27001:2022 with Amendment 1:2024 and ISO/IEC 27002:2022. The starting point is Copla’s Annex A guide. We retain its four-theme structure while checking references and applicability principles against the standards and IAF material.
The examples, acceptance criteria and sample record below are CCyber recommendations. They are not the complete text of the 93 controls or an official reproduction of the standard.
ISMS implementation owners, IT managers, CISOs, process owners and teams preparing for certification. It is particularly relevant to organizations that have a control spreadsheet but cannot yet connect it with risks, accountability and the actual scope of protection.
ISO/IEC 27001 establishes ISMS requirements. Clauses 4-10 concern management of the system, not merely technical safeguards. They cannot be excluded when claiming conformity. This is explained in the official IEC description of ISO/IEC 27001.
Annex A is part of ISO/IEC 27001. It supports comparison of the controls an organization needs against an organized reference set. It does not restrict the organization to that set alone.
ISO/IEC 27002 provides implementation guidance. It is not a separate ISMS certification standard. The relationship is explained by ISO.
Keep references precise. A.8.2 in Annex A concerns privileged permissions. Clause 8.2 in the main body of ISO/IEC 27001 concerns a different subject. Omitting the prefix and document reference can direct a team to the wrong requirement.
The structure and numbering can be checked in the public preview of ISO/IEC 27002:2022. The examples below illustrate a proposed working approach, not the complete wording of individual controls.
The references run from A.5.1 to A.5.37. This theme covers areas including responsibilities, information-handling rules, suppliers, incidents and continuity.
Practical example: before purchasing a cloud service, agree which data it may process, who manages access and how the relationship will end. Approving an invoice does not document those decisions.
Question for the process owner: who decides, and what demonstrates that the agreed arrangements are followed?
The references run from A.6.1 to A.6.8. This theme covers the organization’s relationship with personnel, awareness, remote work and event reporting.
Practical example: following training, an employee should know how to report sending a document to the wrong person. An attendance record confirms participation, not necessarily the ability to perform that action.
Question for HR and security: are the rules also understood by new joiners and external personnel?
The references run from A.7.1 to A.7.14. They address premises, equipment, media and the physical conditions surrounding information protection.
Practical example: remote working does not remove questions about a stolen laptop, a document left in a shared workspace or a storage device sent for disposal.
Question for the organization: are we assessing the actual places where information is used and stored, or only the registered office?
The references run from A.8.1 to A.8.34. This theme includes access, devices, vulnerabilities, configuration, backups, event records, networks and software development.
Practical example: a security-tool licence does not establish whether every important system is covered or who handles detected issues.
Question for IT: which technical and operational result would demonstrate that the safeguard works across its declared scope?
The Copla article requires reference corrections. Backup belongs under A.8.13, not A.8.8. A.6.8 concerns reporting information security events rather than privileged permissions. In working documentation, verify the reference, subject and standard edition together.
A.8.2 concerns privileged permissions, while A.8.5 concerns secure authentication.
Our recommendation: separately check whether a person can establish their identity and whether they receive appropriate permissions. Successful authentication does not justify administration of the entire environment.
A.8.8 addresses technical vulnerabilities, while A.8.9 addresses configuration management.
Our recommendation: compare patching results with configuration reviews. An installed patch does not demonstrate that access is appropriately restricted or unnecessary functionality disabled.
A.8.15 addresses logging, while A.8.16 addresses monitoring activities.
Our recommendation: verify not only that records exist, but also who receives significant signals and how they are handled. A folder containing logs does not identify who will notice an unauthorized change.
Further account-management examples are available in the Identity, Access and Cloud Security category.
The purpose explains the outcome a control is intended to support. However, a descriptive “Control Objective” column in an online guide should not be treated as the standard’s official wording.
IAF MD 26 explains the structural change: ISO/IEC 27002:2022 provides a purpose for individual controls rather than retaining the earlier arrangement of objectives for control groups.
We recommend separating the standard reference, the organization’s implementation and the acceptance criterion. This prevents an internal procedure from being presented as a verbatim ISO requirement.
Not automatically, but no entry should be overlooked without consideration. The organization first determines necessary controls and then compares them with Annex A to identify potential omissions. IAF confirms this comparison role.
The starting point should be the ISMS scope, risks and applicable requirements. Organization-specific controls or controls from other sources may also be needed. Annex A is not the maximum permissible extent of protection.
CCyber recommendation: do not use one field to indicate both whether a control is necessary and whether it has been implemented. “Not implemented yet” does not mean “not applicable”. Similarly, implementation priority is not an exclusion decision.
Clause 6.1.3(d) requires a document identifying necessary controls, the reasons for including them, their implementation status and justifications for Annex A exclusions. The provision is available in the public preview of the standard.
The SoA does not replace the risk treatment plan. The standard also requires risk owners to approve that plan and accept residual risks. Residual risk is the risk remaining after the selected treatment is considered.
Beyond the required content, we suggest linking each record with its owner, systems, procedures, evidence and open actions. These can be maintained in separate connected registers. The entire documentation set does not need to be placed in one spreadsheet cell.
Important: detailed implementation notes, test dates and ticket references are practical additions to the proposed model. We do not present them as mandatory column names prescribed by ISO.
A justification should reflect the actual scope and protection needs. “We have no budget” or “nobody has asked before” is insufficient. The following examples show how to examine these decisions.
Establish what remains with the organization: user devices, permissions, service configuration and provider oversight. Instead of excluding an entire theme, describe the allocation of activities and relevant assurance.
Determine whether the company commissions development, maintains its own integrations or makes significant modifications. The absence of an employed developer does not by itself resolve the applicability of development-related safeguards.
Distinguish non-applicability from external delivery. In the proposed register, identify the service, retained responsibilities and evidence covering the provider’s activities. Do not mark implementation complete solely on the basis of marketing material.
Illustrative CCyber scenario, not a description of a particular client. A company uses an external application-support provider. Its assessment identifies a need to improve support permissions. The following record illustrates how the SoA can connect with delivery.
Reference: A.8.2, privileged permissions.
Reason for inclusion: support personnel can change application configuration and affect service availability. Their access therefore needs restriction and oversight.
Scope: the specified production application and external administrator accounts. Other systems require separate assessment.
Status: necessary control, partially implemented. Authentication operates, but the permission review and removal arrangements remain incomplete.
Proposed action: establish required roles, the access approver, activation conditions and termination arrangements. Perform a controlled check using a test account.
Acceptance criterion: the account can perform the agreed tasks, cannot perform activities outside its approved scope and cannot regain access through the tested route after permissions are removed.
Evidence: the owner’s decision, role configuration, review record and test result. Materials are retained in an approved repository without passwords or secrets.
This record may link to authentication and logging activities, but it does not automatically establish fulfilment of every related control.
We recommend distinguishing three perspectives: rules, configuration and performed activities. A policy describes expected behaviour. A configuration shows settings. A process record or test report helps demonstrate the result within a defined scope.
Example: a rule requires access reviews, and a system can generate the relevant report. However, a completed review with decisions and implemented changes demonstrates that the activity actually took place.
NIST SP 800-53A can support assessment design. It is a control-assessment methodology, not a substitute for ISO/IEC 27001 or a requirement to adopt the entire NIST control catalogue.
Evidence should make its scope and date clear. Do not present a test of one application as a result for every system. Share sensitive configuration material only with authorized recipients.
Saying “we implemented 80 of 93 controls” does not establish whether selection was appropriate, which gaps matter or whether the management system operates.
We suggest separately reporting applicability decisions needing clarification, necessary controls not yet implemented, implementations awaiting verification and overdue remediation.
Define each measure. “The proportion of verified controls within a selected scope” differs from “the company’s overall ISO 27001 compliance level”.
First establish the baseline: confirm the standard edition, control references and ISMS scope. Do not update an old spreadsheet merely by changing the date in its header.
Then examine the reasons: select several risks and check whether they lead to specific controls. Reverse the exercise and ask why each selected control is necessary.
Finally verify operation: choose a representative service and compare declarations with its actual state. Record gaps, owners and closure criteria. Do not postpone urgent protection until the entire register is finished.
The EU Cyber Regulations and Compliance category explores requirements and evidence preparation. Product-security examples are available in the Secure Software and Digital Product Development category. These links lead to Polish-language resources.
This article focuses on selecting and implementing Annex A controls. It is not a complete certification schedule or an assessment against a specific law.
The CCyber ISO/IEC 27001 readiness assessment covers gaps, priorities, required policies and procedures, and a staged implementation plan.
Check whether your Statement of Applicability reflects the actual environment. The current SoA, ISMS scope and open-action list can support scoping the review. A readiness assessment helps prepare the organization, but it is not the issuing of a certificate by a certification body.
No. One procedure may support several controls, while one control may require several processes and configurations. Organize documentation around how the business operates while retaining traceability to the appropriate references.
Do not start with the tool. A controlled document or register can hold the SoA. Consistency, versioning, permissions and connections with implementation matter. Software does not make applicability decisions for the organization.
Not where the control is necessary. Non-implementation belongs in its status and action plan. An exclusion justification answers a different question from a task’s delivery deadline.
Do not treat a frequency stated in an online guide as an automatic requirement of the standard. Establish needs, roles and how competence and awareness will be demonstrated. Separate requirements applicable to the organization may specify a frequency.
In Annex A of ISO/IEC 27001:2022, with implementation guidance in ISO/IEC 27002:2022. Use the appropriate edition available through ISO, IEC or an authorized distributor. A descriptive blog overview does not replace the standard’s wording.
Annex A helps organize protection, but implementation value comes from decisions and operation. Correct references are the starting point. Justification, appropriate scope, ownership and verification must follow.
A useful Statement of Applicability connects what the organization needs with what it actually does. It does not hide gaps behind “not applicable” or treat a purchased tool as evidence of effectiveness.
We write about regulations such as NIS2, DORA, CRA and ISO 27001, cybersecurity for SMEs and critical infrastructure, as well as cyber hygiene, emerging threats and building security awareness within organisations.
Every article delivers practical knowledge - no jargon, just concrete steps you can act on to effectively protect your data, people and business continuity.