Legal AI in EU and the UK: Key Risks and Limitations in 2026
A legal AI tool can summarize hundreds of pages in minutes and still overlook the one sentence that changes the outcome of a matter. It may return a confident, polished answer based on an outdated rule, mix up jurisdictions, or expose confidential information when connected to the wrong data environment. In practice, these are not arguments against using AI in legal work. They are reminders that legal AI needs stronger controls than a general-purpose productivity tool. The real question is not simply whether a model can produce a useful answer, but what data it can access, how its output is verified, and where human review remains mandatory. This is particularly important in regulated and data-sensitive environments. In AI projects, the model itself is often only one part of the risk. Data flows, access permissions, system architecture, retention policies, and review procedures can be just as important as the quality of the generated response. This article looks at the main limitations of generative AI in legal software and the safeguards that should be considered before these tools are used on live client matters. It focuses primarily on the European Union and the United Kingdom, where the regulatory framework is currently more developed. Europe, the Middle East, and Africa should not be treated as a single legal environment. Firms operating in Switzerland, the Gulf states, or African jurisdictions will need to assess local data protection requirements, professional secrecy obligations, and rules governing the provision of legal services. The underlying operational principle, however, remains similar: the more sensitive the legal task and the data involved, the stronger the controls around the AI system need to be. 1. Key Takeaways for 2026 Legal AI risk in Europe is both technical and regulatory; hallucinations are only one part of the picture. EU and UK requirements differ, and the wider EMEA region cannot be covered by a single legal conclusion. Not every legal AI tool is high-risk under the AI Act, but every use case should be classified and documented. Confidentiality, privilege, professional secrecy, and data protection require separate analysis. AI4Legal can support document-based work across jurisdictions, but it does not automatically supply or update the applicable national law. Human review must be qualified, source-based, and built into the workflow rather than added as a disclaimer. A trustworthy implementation combines grounded outputs, controlled data, auditability, testing, and clear responsibility. 2. Why Legal AI Risk Matters More in 2026 The regulatory environment has moved from general principles to operational obligations. In the EU, the AI Act now applies in stages. Prohibited practices and AI literacy obligations have applied since 2025, while additional governance, enforcement, and transparency provisions became applicable in 2026. The precise obligations depend on the system’s intended purpose and on whether an organization acts as a provider, deployer, importer, or distributor. The European Commission maintains the current AI Act enforcement timeline. The UK follows a different model based on existing legislation and sector regulation. In August 2026, the Solicitors Regulation Authority issued a warning focused on inaccurate AI-generated content, client confidentiality, legal professional privilege, data protection, and inadequate supervision. The message is consistent across both regimes: using AI does not transfer responsibility away from the firm or the professional approving the work. See the SRA warning notice. This makes legal AI governance a current management issue rather than a future compliance project. Firms need to know which tools are being used, what information enters them, what sources they rely on, who checks their outputs, and how incidents are reported. 3. Core Limitations of Generative AI in Legal Software 3.1 Hallucinations and Unsupported Legal Authority Large language models generate statistically plausible text. They do not independently determine whether a proposition is legally correct. An answer may contain a nonexistent case, an inaccurate quotation, a real authority applied to the wrong issue, or a source that no longer reflects the law. Fluency can make these errors harder to detect because an incorrect answer may look as polished as a correct one. Retrieval-augmented generation can reduce this risk by grounding answers in selected material, but it does not eliminate it. A peer-reviewed Stanford study of leading legal AI research tools found material rates of hallucinated or unsupported answers even in specialist systems. The practical control is therefore not a promise that a model is hallucination-free, but a workflow that exposes sources and requires proportionate verification. 3.2 Jurisdiction and Context Gaps European legal work is particularly sensitive to jurisdiction. EU law, national legislation, local procedural rules, regulator guidance, and contractual choice-of-law clauses may all affect the answer. The UK is legally distinct from the EU, while privilege and professional secrecy are not defined identically across European jurisdictions. A system that does not reliably identify the relevant country, court, date, and hierarchy of authority can combine individually plausible statements into a legally incorrect conclusion. AI can support research and document analysis, but it should not be treated as a substitute for the professional judgment required to identify the controlling rule, interpret ambiguity, or decide how law applies to disputed facts. 3.3 Confidentiality and Data Protection Legal documents often contain personal data, special-category data, commercially sensitive information, litigation strategy, and information protected by professional secrecy or legal professional privilege. Entering that material into an AI service can create exposure if prompts or files are retained, accessed by unauthorized personnel, transferred internationally, or used to improve a model. Under the GDPR and UK GDPR, firms must identify their role, establish a lawful basis, limit processing to what is necessary, provide appropriate information, control processors and subprocessors, set retention periods, secure international transfers, and implement measures appropriate to the risk. A data protection impact assessment may be required where the proposed processing is likely to result in a high risk to individuals. The UK’s Information Commissioner’s Office also provides detailed guidance on AI and data protection. Confidentiality and privilege should be assessed separately from data protection. Processing may have a GDPR basis and still violate a professional duty, client instruction, engagement term, or court restriction. 3.4 Bias, Incomplete Data, and Uneven Performance AI outputs reflect the data, retrieval process, instructions, and evaluation criteria behind the system. Historical imbalance, missing jurisdictions, language coverage, poor document quality, or inconsistent labeling can produce uneven results. Bias may appear in risk scoring, document prioritization, settlement analysis, or recommendations that seem neutral but systematically underperform for certain matters or groups. Evaluation should therefore use representative legal tasks and documents, including difficult examples, minority languages, scanned files, conflicting authorities, and cases where the correct response is to flag uncertainty rather than provide a confident answer. 3.5 Limited Explainability and Source Traceability A lawyer does not always need a technical explanation of every model parameter, but the legal work product must be reviewable. Users should be able to identify the documents or authorities supporting an answer, distinguish quotations from generated analysis, check the version and date of the source, and understand when the system lacks sufficient evidence. A citation interface is not enough if the cited source does not support the proposition. Trustworthy systems should make source checking easier, not merely attach links to generated text. 3.6 Overreliance and Automation Bias Fast, well-written output creates a risk of automation bias: users may apply less scrutiny to a machine-generated draft than they would to work produced by a colleague. Repeated reliance can also weaken research habits and reduce the likelihood that lawyers will notice jurisdictional or factual anomalies. Human-in-the-loop review is effective only when the reviewer has enough time, authority, subject-matter knowledge, and access to the underlying sources to challenge the system. 4. The EU AI Act and Legal Services The AI Act does not classify every legal AI application as high-risk. Risk classification depends on the intended purpose and context. Internal document summarization, clause extraction, or knowledge search will not automatically become high-risk merely because a law firm uses the tool. By contrast, certain systems used by or on behalf of judicial authorities to research and interpret facts and law and to apply law to concrete facts may fall within the high-risk categories when the relevant provisions apply. The Commission’s AI Act overview explains the risk-based structure and implementation dates. For legal organizations, the first compliance question is often role and use case rather than model brand. A firm that deploys a third-party tool, materially modifies it, places it under its own name, or develops a client-facing system may have different obligations. Procurement and product teams should document this assessment instead of assuming that the vendor alone carries regulatory responsibility. Article 4 also makes AI literacy an operational requirement for providers and deployers. Training should reflect the person’s role, the system’s purpose, and the people or groups affected. Generic awareness training is unlikely to be sufficient for lawyers approving court submissions, administrators configuring access, or developers changing retrieval sources. Article 50 introduces transparency obligations for specified AI systems and content. These rules do not require every internal AI-assisted draft to carry the same label, but they do require a use-case analysis. The Commission published guidelines on the 2026 transparency obligations to clarify when providers and deployers must inform people or mark generated content. 5. UK Professional Duties and Court Expectations UK firms must consider the SRA Principles and Codes of Conduct, duties to the court, confidentiality, legal professional privilege, UK data protection law, and the firm’s supervision arrangements. The SRA’s guidance emphasizes that an authorized individual must retain responsibility for legal services delivered with AI assistance and that AI-generated work requires appropriate human scrutiny. The risk is visible in litigation. In Ayinde v London Borough of Haringey and Al-Haroun v Qatar National Bank, the High Court examined legal materials containing false authorities and stressed the responsibility of legal representatives to verify material placed before the court. The relevant lesson is not that AI is prohibited. It is that the duties of accuracy, supervision, and candour continue to apply regardless of how a document was drafted. Firms operating across the EU and UK should avoid treating one policy as universally sufficient. The same technical platform may require different notices, contractual provisions, approval paths, and professional controls depending on jurisdiction and use. 6. Intellectual Property, Contracts, and Vendor Risk Legal AI procurement should address more than cybersecurity. Contracts need to define permitted data use, model training, subprocessors, retention and deletion, incident notification, audit rights, service continuity, output ownership, confidentiality, liability, and support for regulatory requests. Firms should also confirm that they have the right to upload third-party documents and that generated content is checked for infringement and unauthorized reproduction. Security or AI management certifications can support due diligence, but they are not a legal safe harbour and do not establish the accuracy of legal output. The assessment should connect each control to the actual deployment architecture and use case. 7. What Sets a Trustworthy Legal AI System Apart Defined purpose and jurisdiction: the system is designed for specified tasks, users, countries, languages, and source sets. Grounded and reviewable output: users can open the supporting material, verify quotations, and see when the system lacks evidence. Controlled data environment: client data is segregated, access is restricted, retention is defined, and data is not used for model training unless expressly authorized. Human approval at meaningful decision points: qualified professionals review advice, filings, client communications, and other high-impact outputs. Logging and auditability: the organization can reconstruct the input, sources, model or configuration, output, reviewer, and final decision where appropriate. Representative evaluation: accuracy, retrieval quality, security, bias, and failure modes are tested before launch and monitored after changes. Clear responsibility: the vendor, firm, product owner, information security team, data protection function, and legal reviewer each have defined obligations. 8. European Legal AI in Practice: TTMS and Sawaryn & Partners A practical example comes from TTMS’s work with Sawaryn & Partners, a Polish law firm. The firm needed to process large volumes of case documents, court records, meeting notes, and recordings. TTMS implemented an Azure OpenAI-based application that generates summaries and supports document updates. According to the published case study, the architecture was designed so that input data and generated results were not shared with external organizations or used to train neural networks. AI4Legal is not limited to a single jurisdiction. Its document-based architecture allows it to support legal document analysis in EU Member States, the United Kingdom, the United States, and other markets because it works with materials supplied to the system rather than automatically retrieving a national code or body of case law. This makes the platform adaptable across jurisdictions without implying that it contains a complete, continuously updated database of each country’s law. The case demonstrates an appropriate use of AI to support document-intensive legal work within a controlled environment. Jurisdictional flexibility does not make the output error-free: results depend on the completeness, accuracy, and currency of the uploaded materials. Legal professionals must still verify controlling law, citations, and conclusions under the rules applicable to the matter. The value lies in matching the technology to a defined workflow, protecting the data, and keeping legal review with the firm. Sawaryn & Partners also publishes practical commentary on AI Act roles and obligations, illustrating the need to connect technical implementation with legal governance. 9. How to Safeguard a Legal Organization Create an AI inventory. Record approved and unapproved tools, owners, users, data categories, integrations, jurisdictions, and intended purposes. Classify each use case. Assess AI Act role and risk, data protection impact, professional secrecy, privilege, client terms, court requirements, and local professional rules. Set data-entry rules. Define which information may be used, which environments are approved, and when anonymization or synthetic data is required. Perform vendor and architecture due diligence. Review data flows, training settings, storage locations, subprocessors, access controls, deletion, incident response, contractual protections, and exit arrangements. Design verification by task. Court citations, legal advice, deadlines, calculations, quotations, and client-facing content need explicit checking against authoritative sources. Train for real roles. Lawyers, support staff, developers, procurement teams, and managers need different training and escalation paths. Monitor the live system. Re-test after model, prompt, source, or integration changes and track errors, overrides, complaints, and near misses. Prepare an incident process. Staff should know how to stop use, preserve evidence, correct affected work, inform decision-makers, and assess notification duties. 10. Balancing Risk and Value AI can reduce time spent searching, organizing, comparing, and summarizing information. It can also improve access to large document sets that would otherwise be difficult to review consistently. These benefits are real, but they depend on use-case design and cannot be assumed from the model name or a vendor demonstration. The strongest approach treats AI as part of a controlled legal process. The system handles defined computational or language tasks; professionals remain responsible for legal judgment, source validation, confidentiality, and the final decision. This balance allows firms to gain efficiency without presenting automation as a replacement for professional accountability. FAQ Is legal AI prohibited under the EU AI Act? No. The AI Act uses a risk-based framework. Obligations depend on the intended purpose, risk category, and role of the organization. Many internal productivity tools will not be high-risk, although other AI Act, GDPR, contractual, and professional requirements may still apply. Can a law firm enter client documents into a generative AI tool? Only after confirming that the use is lawful and consistent with confidentiality, privilege, client instructions, professional rules, and the tool’s contractual and technical safeguards. Public consumer tools should not be treated as approved environments for confidential legal material. Do lawyers have to verify every AI-generated citation? Any authority relied on in advice, a filing, or another material legal conclusion should be checked against an authoritative source. The extent of review for lower-risk administrative tasks can be proportionate to the task and the tested reliability of the system. Does a security certification make legal AI compliant? No. Certifications may provide useful assurance about selected controls, but compliance depends on the actual use case, data flow, configuration, contracts, governance, and legal obligations. They do not establish legal accuracy. Should clients be told that AI is being used? Sometimes. The answer depends on applicable transparency rules, professional duties, engagement terms, client expectations, the materiality of the AI-supported task, and how client information is processed. Firms should define disclosure triggers rather than use a universal statement. Can AI replace a lawyer's legal judgment? No. AI can support research, document analysis, drafting, and knowledge retrieval, but responsibility for legal advice, strategy, filings, and professional obligations remains with qualified people and regulated organizations.
Read
AQAP 2210 in Defence IT Projects: Software Quality Requirements
In a defence project, software quality does not end with an application working correctly on the acceptance date. The customer needs control over requirements, configuration, changes, testing, subcontractors and the evidence demonstrating that the product complies with the contract. The customer must also know which version was delivered, on what basis it was accepted and whether it can be maintained and developed safely. AQAP 2210 brings structure to these matters at software project level. The publication sets out NATO requirements for software quality assurance and is used as a supplement to AQAP 2110 or AQAP 2310. Its significance, however, does not arise merely from the use of the acronym AQAP. In practice, the requirements of the specific contract, the scope of supply, software criticality and the agreed arrangements for oversight and acceptance are decisive. For the customer, this means that selecting an IT supplier should involve much more than assessing technology, developer availability and price. The organisation needs a partner capable of developing software under controlled conditions, maintaining traceability and producing credible quality evidence. This article explains how to interpret AQAP 2210 requirements and apply them when selecting an IT supplier for the defence sector. KEY TAKEAWAY: AQAP certification is important evidence of the maturity of a supplier’s quality management system. It does not, however, replace analysis of the specific contract requirements or the quality evidence generated during project delivery. 1. AQAP 2210 at a glance AQAP 2210 addresses software quality assurance in projects delivered in a defence environment. The current publication is AQAP 2210, Edition B, Version 1, issued in 2022. It supplements AQAP 2110 or AQAP 2310 and is not designed as a completely standalone set of requirements. Its application to a project primarily results from the contract, procurement specification and referenced quality documents. It covers management and technical processes, including quality planning, criticality analysis, requirements, configuration, verification, validation, testing and subcontractor control. It does not mandate a single software development model. It can coexist with Agile and DevSecOps provided that the organisation maintains control, accountability and objective evidence. A supplier’s certificate does not automatically demonstrate the compliance of every product or project. The certification scope, contract requirements and application of processes to the specific undertaking all matter. 2. What is AQAP 2210? AQAP stands for Allied Quality Assurance Publications. The AQAP family supports a common approach among NATO nations to the quality of defence supplies. Its purpose is to increase confidence that a supplier can deliver a product that meets contractual requirements and provide the customer with appropriate visibility of processes affecting quality. AQAP 2210, Edition B, Version 1, contains NATO supplementary software quality assurance requirements. It is project-oriented and covers both management and technical processes. It does not prescribe a particular software methodology, programming language, tool or architecture. Its purpose is to establish a level of planning, control and evidence that gives the customer justified confidence in both the process and the product. AQAP 2210 is to be used in conjunction with AQAP 2110 or AQAP 2310, depending on the core set of requirements referenced in the contract. In Poland, current publications used in certification processes are described by the Polish Centre for Testing and Certification and the Quality Certification Centre of the Military University of Technology. The status of AQAP 2210 Edition B as an active publication can also be verified in the US ASSIST standardisation document database. 2.1 A contractual requirement, not universally applicable legislation AQAP 2210 should not be presented as legislation that automatically applies to every company developing defence software. Binding obligations arise primarily from the contract, specification, quality clause and documents referenced by the customer. In one project, AQAP 2210 may cover the full development lifecycle of a new system. In another, it may apply to the modification of an existing solution, component integration or software maintenance. Requirements may be subject to justified tailoring where the publication and the customer permit it. Such decisions should nevertheless be transparent, approved and documented. A supplier should not independently declare an inconvenient requirement inapplicable. 3. AQAP 2110 and AQAP 2210: what is the difference? AQAP 2110 and AQAP 2210 are related but perform different functions. AQAP 2110 establishes broad quality assurance requirements for design, development and production. AQAP 2210 expands on these requirements for software and for work performed at individual project level. Area AQAP 2110 AQAP 2210 Principal scope Quality assurance in design, development and production Supplementary software quality assurance Role Core set of quality assurance requirements Software-specific supplement to AQAP 2110 or AQAP 2310 Perspective Supplier quality management system and product delivery Project, processes and software-related evidence Example areas Planning, risk, suppliers, nonconformities and delivery oversight Project Software Quality Plan, criticality, requirements, SCM, V&V and testing Application Depends on contract requirements and the type of supply Applies when the contract covers software and references the relevant requirements Standalone use May serve as the core quality publication Used in conjunction with AQAP 2110 or AQAP 2310 ISO 9001 remains an important foundation for systematic quality management, but it does not describe every mechanism needed in a defence project or the detailed quality requirements for software. Assessment of a potential partner should therefore go beyond asking whether the company holds ISO 9001 certification. The customer should establish whether the supplier’s system covers the relevant AQAP scope and whether the organisation can apply it to the specific project. 4. When does AQAP 2210 apply to an IT project? The contractual documentation provides the most reliable answer. The requirement may be stated directly in the contract, procurement specification, quality clause or quality plan, or in requirements imposed on the prime contractor and flowed down to subcontractors. AQAP 2210 may be relevant to projects involving: development of new bespoke software; development or substantial modification of an existing system; software maintenance and support; integration of software with hardware, sensors, effectors or platforms; command, control and situational awareness systems; C2, C4ISR and combat support systems; embedded software or a component forming part of a larger product; use or modification of commercial off-the-shelf software; delivery of a software component by a subcontractor to the prime contractor. The mere presence of code in a product does not, however, determine an identical scope of requirements. An application supporting an administrative process may require different controls from a component affecting a critical function. Before work begins, the parties should therefore identify at least the scope of supply, their respective responsibilities, software criticality, dependencies, acceptance arrangements and the evidence required by the customer. 4.1 Questions to ask before signing the contract Which AQAP publications and editions are referenced? Do the requirements apply to the entire supply, a specific component or selected processes? Is tailoring permitted and, if so, who approves it? What oversight and access rights are granted to the customer or Government Quality Assurance Representative? Which plans, records, reports and evidence are required for reviews and acceptance? Which obligations must be flowed down to subcontractors? How will software criticality be assessed, and how will it affect the rigour of project activities? Clarifying these points early reduces the risk of costly rework to documentation, testing processes or the supply chain once delivery is under way. 5. Why does AQAP 2210 matter to the customer? In a conventional commercial project, some ambiguities can be resolved by renegotiating scope or moving a deadline. In a defence project, the consequences of an incorrect configuration, incomplete test or loss of traceability may be much more serious. The system may interact with hardware, process operationally significant data or operate in an environment with limited connectivity and elevated threats. AQAP 2210 helps the customer reduce risks including: delivery of functionality that does not comply with contractual requirements; changes introduced without impact assessment and approval; absence of links between requirements, design, code and test results; inability to identify unequivocally the configuration submitted for acceptance; detection of critical defects only during acceptance testing; lack of objective evidence that tests were performed; uncontrolled use of external components; insufficient oversight of subcontractors; loss of knowledge needed to maintain and further develop the system; closure of a nonconformity without confirmation that the correction was effective. The principal value is therefore not the number of documents produced, but transparency. The customer can verify how the supplier interprets requirements, controls work, manages open risks and determines that a product is ready. 6. Key AQAP 2210 requirements in a software project AQAP 2210 covers numerous interrelated processes. Their detailed application depends on the contract, but the areas below are among the most important when assessing a supplier and planning delivery. 6.1 Project Software Quality Plan The Project Software Quality Plan should demonstrate how the organisation will meet the quality requirements of a specific undertaking. It is not a general quality policy or a document produced only immediately before an audit. A robust plan connects contractual requirements with the actual way in which the team works. It defines the scope, roles, responsibilities, lifecycle, reviews, verification and validation methods, configuration management, subcontractor control, metrics and required records. It should also identify dependencies between documents and explain how the plan will be updated when the project changes. The customer should be able to use it to understand not only what the supplier declares, but also when evidence will be provided, who will make decisions and how deviations will be handled. 6.2 Software criticality analysis Criticality helps align the rigour of project activities with the consequences of a potential failure. The analysis should consider the function of the software, its relationship with the overall system and the potential effect of malfunction on people, the mission, equipment, information and continuity of operations. The outcome may affect the independence of reviews, test scope, required coverage, reporting frequency, level of change control and treatment of risk. The objective is not to impose the most expensive controls on every component, but to reach a conscious, documented and justified decision. 6.3 Requirements management and traceability Requirements should be unambiguous, verifiable and subject to change control. The supplier must understand system, software and component requirements, together with constraints arising from architecture, interfaces, security and the operating environment. Traceability makes it possible to move from a requirement to the design solution, implementation and test, and then back from the test result to the contractual basis. It may be maintained in a matrix or a dedicated tool. What matters is that it remains current and reveals requirements without design coverage, code without justification or tests without a corresponding requirement. In a mature project, a requirement change triggers an assessment of its impact on architecture, code, tests, documentation, schedules and subcontractors. Updating a backlog item alone is insufficient if the remaining evidence is left out of date. 6.4 Software configuration management Software configuration management, or SCM, provides unambiguous identification of product items and control over their changes. It does not concern source code alone. Its scope may include requirements, models, scripts, environment configurations, libraries, documentation, test data, tools, build artefacts and installation packages. The customer should expect clear answers to practical questions such as: Which items make up a particular product version? Who approved a change, and on what basis? Can the build submitted for testing or acceptance be reproduced? How are the status of changes and nonconformities recorded? Does the supplier control dependencies, libraries and tool versions? How are repositories protected and access restricted? Without these mechanisms, even correctly tested functionality may enter the wrong release or be overwritten by a later change. 6.5 Verification, validation and testing Verification asks whether the product has been built in accordance with specified requirements and design. Validation establishes whether the solution meets the needs and intended use in its target context. In practice, both types of activity should be planned, have defined criteria and owners, and produce retained results. The test programme may cover unit, integration, system, performance, security, resilience and acceptance testing. The scope depends on the product and contract. Key considerations include: linking tests to requirements; defined test environments and test data; identification of the product version under test; test entry and exit criteria; results, deviations and evidence of execution; separation of roles where independence is required; handling of defects, retesting and regression testing. Automation can improve repeatability, but a pipeline report is not complete evidence on its own if it does not identify what was tested, which version was used and which criteria governed the assessment. 6.6 Nonconformities and corrective action The supplier should operate a controlled process for recording, assessing and closing nonconformities. A correction that addresses an immediate defect should be distinguished from corrective action intended to eliminate its cause. The record should make it possible to determine the impact of the problem, affected versions, the disposition decision, responsibility, retest results and any need to inform the customer. Recurring problems should lead to trend analysis and an assessment of process effectiveness, rather than another sequence of isolated code fixes. 6.7 Subcontractors, COTS and external components Modern software uses libraries, tools, services, devices and ready-made components. AQAP 2210 does not allow them to be treated as areas outside the supplier’s responsibility. The organisation should assess a component’s suitability, constraints, rights of use, documentation, configuration and effect on requirements. For commercial off-the-shelf software, objective grounds are needed to establish that the product will fulfil the required function. Where full traceability is not possible, the limitation should be identified, assessed and appropriately managed. Modifying ready-made software may also change the risk profile and responsibility for maintenance. The same principle applies to subcontractors. The prime contractor should specify requirements, monitor performance and retain evidence of oversight. A subcontractor’s certificate may support qualification, but it does not release the prime contractor from responsibility for compliance of the overall supply. 7. Can Agile and DevSecOps be reconciled with AQAP 2210? Yes. AQAP 2210 does not prescribe a single lifecycle model or mandate a waterfall approach. Agile and DevSecOps can be used if the organisation can demonstrate control over requirements, configuration, testing, accountability and releases. Agile or DevSecOps practice Corresponding quality mechanism Product backlog Controlled record of requirements, priorities and changes Definition of Ready Criteria establishing that a requirement is ready for implementation Definition of Done Quality, testing, documentation and acceptance criteria Pull request and code review Documented review and approval of a change Code repository Item identification and configuration control CI/CD Repeatable build, automated controls and retained results Test management Link between requirement, test case, product version and result Release pipeline Controlled release and unambiguous identification of its contents Retrospective Process improvement and corrective action The most common mistake is to equate agility with an absence of documentation. Documentation in an Agile project may be lighter, generated automatically and maintained in tools. It must nevertheless remain credible, accessible and understandable to those responsible for oversight. A second risk is excessive reliance on automation. A pipeline may execute thousands of tests, but the customer also needs context: the product version, test scope, criteria, deviations and approval. DevSecOps supports AQAP when it automates a controlled process, not when a stream of logs obscures the absence of accountability. 8. What documents and evidence may the customer expect? The final evidence set is determined by the contract. There is no single file or binder suitable for every project. In practice, the customer may expect materials such as: Area Examples of documents and records Control question Planning Project Software Quality Plan, review schedule and responsibility matrix Is it clear who makes each decision, when and against which criteria? Requirements Specifications, change history, traceability matrix and review records Does every requirement have a source, an owner and a verification method? Configuration SCM plan, configuration item list, baselines and release register Can the exact version delivered to the customer be reproduced? Testing Plans, cases, data, reports, results and defect records Does the result relate to the correct version and an approved requirement? Nonconformities Problem reports, decisions, root-cause analysis and retest records Has the problem been effectively resolved rather than merely marked closed? Suppliers Qualification criteria, assessments, purchasing requirements and reviews Have quality obligations been flowed down and are they monitored? COTS and dependencies Suitability assessment, versions, licences, constraints and functional evidence Does the organisation understand the risk and can it maintain the component? Acceptance and delivery Release documentation, acceptance results and list of deviations Are the contents of the delivery and any remaining limitations unambiguous? Evidence should be credible, current, linked to the relevant scope and reproducible. A screenshot without a date, version or owner has limited value. Equally, a policy describing a process does not demonstrate that the process was actually applied to the project. 9. What does AQAP certification demonstrate, and what does it not guarantee? Certification of a quality management system by a competent body is an important signal to the customer. It shows that a defined scope of the organisation’s activities has been assessed against the specified requirements and that the company maintains processes necessary for controlled delivery. A certificate may demonstrate: implementation and maintenance of a quality system conforming to a specified AQAP publication; assessment of the stated scope of activities and locations; the existence of controlled processes, responsibilities and records; periodic third-party assessment of the system; an organisational foundation for performing contracts that require AQAP. A certificate does not automatically guarantee: compliance of every project with every contract; a defect-free product; fulfilment of requirements outside the certification scope; possession of every clearance, authorisation or domain competence required by the project; effective application of processes without the right team and oversight; acceptance of the supplier by every customer without further qualification. The customer should therefore verify the issuing body, certificate validity, AQAP publication and edition, certification scope, locations and alignment of that scope with the planned procurement. It is also worth asking the supplier to demonstrate how its quality management system will be applied to the specific project. 10. How should you select an IT supplier for a defence project? A capable supplier combines three layers: organisational capability, technical competence and understanding of the defence environment. A weakness in any one of them may become apparent only during integration, oversight or acceptance. 10.1 Customer checklist [ ] The certification scope covers software development, delivery or maintenance relevant to the planned project. [ ] The supplier can translate contractual requirements into a quality plan and the team’s daily work. [ ] Requirements, design decisions, implementation and tests remain traceable. [ ] Configuration management covers code, documentation, dependencies, environments and releases. [ ] The build submitted for testing or acceptance can be reproduced unambiguously. [ ] The V&V process has defined roles, criteria, environments and retained results. [ ] Nonconformities are assessed, tracked, retested and closed on the basis of evidence. [ ] Subcontractors and COTS components are subject to qualification and monitoring. [ ] The team understands software-hardware integration and constraints of the target environment. [ ] The supplier understands defence systems, NATO standards and work within a supply chain. [ ] It can produce the quality evidence required for reviews, oversight and acceptance. [ ] It can provide maintenance, change management and controlled development after deployment. [ ] The engagement model clearly allocates responsibility for the product, quality, security and decisions. [ ] The experience claimed is relevant to the actual scope and criticality of the procurement. 10. Warning signs during supplier qualification Answers limited to stating that the company is certified or works in Agile should prompt caution. Other warning signs include: inability to explain the certification scope; a quality plan copied without adaptation to the project; no owner for the configuration management process; tests that are not linked to requirements and the product version; subcontractors treated as solely responsible for their own quality, without prime contractor oversight; no controlled process for approving deviations; documentation prepared only immediately before acceptance; inability to explain how changes will be handled after deployment. The best test is a discussion based on a realistic scenario: a high-criticality requirement changes, affects a subcontracted component and requires a new integration test. A mature partner can explain the impact assessment, decisions, configuration update, testing and evidence without hiding behind a generic procedure. 11. Why choose TTMS as a partner for the defence sector? The selection of a technology partner should be based on its fit with the specific undertaking. In the case of TTMS, the relevant strength is the combination of a certified quality management system, technical capabilities and domain experience. 11.1 Certified quality processes TTMS has obtained AQAP 2110 and AQAP 2210 certification, as described in the TTMS press release. For a prospective customer, this confirms that a defined scope of the company’s quality management system has been independently assessed against requirements used in the defence sector and in software quality assurance. Certification is not presented as a substitute for project analysis. It provides an organisational foundation on which to build the quality plan, traceability, configuration management and evidence required by a particular contract. 11.2 Technical expertise and domain knowledge The public TTMS offering for the defence and space sectors includes software development, defence IT engineering services, hardware-software integration, technical consultancy, project management and the provision of specialist teams. TTMS also describes experience involving C2, C4ISR and combat support systems, as well as work in the environment of international organisations. This combination matters because process conformity cannot replace engineering competence. Conversely, even a highly capable software team may struggle in a defence project if it cannot work with contractual requirements, quality oversight and formal evidence. 11.3 A flexible engagement model A project may require a complete solution, a distinct component, integration, a software team or individual specialist capabilities. The model should be selected after analysing the scope, responsibilities and quality requirements. Regardless of the form of engagement, ownership of requirements, configuration, testing, risk and acceptance should be clearly established. TTMS can join the undertaking as a technology partner supporting software development, integration and maintenance. The final obligations, applicable AQAP publications and required evidence should be defined in the documentation of the specific project. 12. What can an engagement with TTMS look like? 12.1 Context and requirements analysis The first stage establishes the purpose of the system, scope of supply, stakeholders, architecture, quality requirements and security constraints. The team identifies the publications and clauses referenced in the contract and areas requiring clarification. 12.2 Definition of the delivery model The parties establish responsibilities, team composition, interfaces with the customer and other suppliers, lifecycle, reviews, tools, configuration and required evidence. This stage should also plan the flow-down of requirements to subcontractors. 12.3 Controlled development and reporting Delivery combines engineering work with requirements, risk, configuration, quality and nonconformity management. The customer receives the agreed visibility of progress, results and open decisions. 12.4 Verification, validation and acceptance Tests and reviews are performed on controlled versions against approved criteria. The acceptance package should unambiguously identify the delivery contents, results, deviations and remaining limitations. 12.5 Maintenance and controlled development After deployment, configuration management, problem handling, updates, change impact assessment and documentation maintenance remain necessary. The support model should reflect the importance of the system and the required availability. 13. Are you looking for an IT partner for a defence project? A defence project requires a simultaneous understanding of technology, quality, integration, security and contractual accountability. It is worth involving the supplier before the architecture and delivery plan are finalised, so that AQAP requirements are not treated as a documentation exercise postponed until acceptance. Contact TTMS to discuss your project’s technical and quality requirements, allocation of responsibilities and a potential engagement model with the Defence team. 14. Frequently asked questions about AQAP 2210 What is AQAP 2210? AQAP 2210 is a NATO publication containing supplementary software quality assurance requirements. It is project-oriented and covers the management and technical processes needed for controlled software development and delivery. What do AQAP 2210 requirements cover? They include software quality planning, criticality analysis, requirements management, traceability, configuration, subcontractors, COTS software, verification, validation, testing and the treatment of nonconformities. The exact scope in a project is determined by the contract. What is the difference between AQAP 2110 and AQAP 2210? AQAP 2110 establishes broad quality assurance requirements for design, development and production. AQAP 2210 expands on software-specific requirements and is used as a supplement to AQAP 2110 or AQAP 2310. Can AQAP 2210 be used on its own? Not as a completely independent set of requirements. The current edition is intended for use as a supplement to AQAP 2110 or AQAP 2310. The applicable combination should be specified in the contract. When is AQAP 2210 required in an IT project? It is required when referenced in a contract, specification, quality clause or requirements imposed on the contractor. The fact that software is being developed for the defence sector does not, without examination of the documentation, establish an identical set of obligations in every case. Does every military software supplier need AQAP certification? There is no universal rule to that effect. The need for certification and its scope depend on the customer, procurement procedure, contract and type of supply. Even where certification is required, its validity and alignment with the project scope should be verified. Is ISO 9001 sufficient for a defence project? ISO 9001 can provide an important quality management foundation, but it does not replace detailed AQAP requirements referenced in the contract. Nor does it describe every mechanism focused on software quality assurance in a defence environment. Is AQAP 2210 compatible with Agile and DevSecOps? Yes. It does not mandate a single development model. The team must nevertheless retain control over requirements, changes, configuration, testing, accountability and evidence. Agile cannot be used to justify a loss of traceability. What documents should a software supplier prepare? Depending on the contract, these may include a Project Software Quality Plan, configuration management plan, requirements register, traceability matrix, review reports, test plans and results, change and nonconformity records, supplier assessments, and release and acceptance documentation. Does AQAP 2210 cover COTS components and subcontractors? Yes. The supplier should oversee subcontractors and assess the suitability, configuration, documentation, constraints and risks of ready-made components. Responsibility for the overall supply does not disappear because part of the solution originates from another organisation. How can the scope of a supplier's AQAP certificate be verified? The issuing body, certificate number and validity, AQAP publication and edition, scope of activities, locations and any exclusions should be checked. The scope should correspond to the work actually entrusted to the supplier. Why choose a supplier certified to AQAP 2110 and AQAP 2210? The certificates can reduce uncertainty regarding the maturity of the quality management system and the organisation’s ability to operate controlled processes. The customer should still assess technical capabilities, domain experience, certification scope and the proposed application of requirements to the specific project.
Read
Microsoft 365 Licensing & Pricing 2026: Complete Buyer’s Guide
What is a company actually buying when it orders Microsoft 365? “Email and Office” has not been a complete answer for years. The decision now touches devices, sign-ins, data protection, meetings, cloud work and, increasingly, Copilot. Not every employee needs all of it. The easiest mistakes happen between plans that look almost the same to the person using them. Word opens, Outlook is there and files save to the cloud. The difference tends to surface later, when IT needs to configure a laptop remotely, enforce an access rule or respond to a threat. At that point, the cheaper license may no longer be the cheaper option. Whatever is missing still has to be provided somehow. The July 1 changes add another complication in 2026. Microsoft raised US list prices for selected Business, Enterprise and Frontline plans and changed the feature set of some packages. Versions with Teams and without Teams are still available, so comparing product names alone does not get a buyer very far. Renewal timing, billing currency, tax and partner terms also affect the quote. The figure in the price list is a starting point, not the final invoice. Copilot has a similar naming problem. Copilot Chat may be available at no additional charge to users with eligible subscriptions, while Microsoft 365 Copilot is a separate paid license that needs an eligible base plan. Buying Copilot does not tidy up company data or permissions. It works with what is already in the organization’s environment – including the gaps and mistakes. This guide looks at the Business, Enterprise and Frontline families, along with Apps for Business, Office 365 E1 and both Copilot options. Instead of searching for one plan that suits everybody, we ask what makes sense for each role. A browser-only employee, an administrator and a frontline worker on a shared device do not need the same license. A practical licensing model starts with those differences and builds from there. This guide uses US commercial list prices before tax. Currency, local market adjustments, partner discounts, agreement type, billing schedule and promotions can change the final amount. Microsoft 365 licensing in one minute If you need a quick answer, use these five rules: Choose Business Basic when users need business email, cloud collaboration and web/mobile apps, but not locally installed Office desktop apps. Choose Business Standard when desktop Word, Excel, PowerPoint and Outlook matter, but advanced device and threat protection will be handled elsewhere. Choose Business Premium when an organization of up to 300 users wants productivity plus Microsoft Intune, Microsoft Entra ID P1 and Microsoft Defender for Business in one suite. Move to Enterprise when the 300-seat Business limit, advanced compliance, enterprise security, Windows Enterprise rights or organization-wide scale requires it. Microsoft 365 E3 is the broad foundation; E5 adds the deepest security, identity, compliance and analytics capabilities. Use F1/F3 for genuine frontline roles and Copilot Chat as the broad AI baseline. Assign paid Copilot to selected people with repeatable, information-heavy work. What changed in Microsoft 365 pricing in 2026? Microsoft’s new commercial US list prices took effect on July 1, 2026. Existing customers stay on their contracted price until renewal. Packaging additions began rolling out in summer 2026, so a tenant may receive a feature after the price effective date; Microsoft provides notice through the Message Center. Plan With Teams: USD/user/month Without Teams: USD/user/month 2026 position Business Basic $7.00 $5.40 Cloud-first SMB suite; price increased Business Standard $14.00 $10.79 Desktop apps for SMB; price increased Business Premium $22.00 $18.79 Security-led SMB suite; price unchanged Apps for Business $10.00 Not applicable Desktop apps and OneDrive; price increased Office 365 E1 $10.00 $6.79 Cloud productivity; price unchanged Office 365 E3 $26.00 $17.45 Productivity suite; not the same as Microsoft 365 E3 Office 365 E5 $41.00 $32.45 Productivity, compliance, voice and analytics Microsoft 365 E3 $39.00 $30.45 Productivity + Windows + identity/device management Microsoft 365 E5 $60.00 $51.45 Advanced security, compliance and analytics Microsoft 365 F1 $3.00 $2.50 Light frontline experience Microsoft 365 F3 $10.00 $8.93 Managed frontline productivity Pricing note: These are Microsoft’s commercial US list prices effective July 1, 2026, before tax, shown as monthly equivalents for annual subscriptions. Availability, currency, billing options and promotions vary. “Without Teams” is a different SKU—not a discount that can simply be switched on later without checking commercial terms. Standalone Teams may need to be purchased separately. The 2026 packaging update also adds value to selected plans. Business Basic and Standard receive a larger email allowance, time-of-click URL protection, Copilot Chat enhancements and analytics. Microsoft 365 E3 receives Defender for Office 365 Plan 1 and additional Intune capabilities. Microsoft 365 E5 receives further advanced Intune features and Security Copilot-related value. Rollout timing should always be confirmed in the tenant. How Microsoft 365 product names fit together The names matter because “Office 365” and “Microsoft 365” are not interchangeable. Office 365 E1/E3/E5 focuses on productivity and cloud services. Microsoft 365 E3/E5 includes the Office 365 layer and adds Windows Enterprise plus broader identity, device management and security rights. There is no mainstream commercial “Microsoft 365 E1” equivalent in this comparison; the cloud-productivity plan is Office 365 E1. Family Designed for User ceiling Typical role Microsoft 365 Business Small and midsize organizations 300 Business-family users per tenant Information workers and SMB operations Office 365 Enterprise Enterprise cloud productivity No Business-family 300-seat ceiling Users needing mail, collaboration and Office services Microsoft 365 Enterprise Integrated productivity, Windows, identity, security and compliance Enterprise scale Managed knowledge workers Microsoft 365 Frontline Workers whose primary role is service, operations or production Enterprise scale; eligibility rules apply Retail, factory, warehouse, field and shift workers Microsoft 365 Copilot AI layer on an eligible base license SKU-dependent; Copilot Business up to 300 Selected high-value knowledge workflows Microsoft 365 Business plans compared All Business base plans are designed for organizations with up to 300 provisioned users across the Business family. They can be mixed—for example, Premium for managed employees, Standard for lower-risk office roles and Basic for browser-first users—provided each person receives the services required for their work. Plan Core productivity Security and management Best fit / main limitation Business Basic $7. Web/mobile Word, Excel, PowerPoint and Outlook; business email; OneDrive; SharePoint; Teams in the with-Teams SKU. Foundational controls; no Intune or Defender for Business. 2026 adds URL protection. Browser-first users. No desktop Office apps; 300-user family limit. Business Standard $14. Everything in Basic plus desktop Office apps and broader collaboration tools. Foundational controls; no integrated advanced device/threat suite. Typical office worker. Strong productivity, but security stack may require separate tools. Business Premium $22. Desktop, web and mobile apps, email and collaboration. Intune, Entra ID P1, Defender for Business and information protection capabilities. Security-conscious SMB. Best all-round suite up to 300 users. Apps for Business $10. Desktop Office apps plus 1 TB OneDrive per user. App deployment controls, but not a full email/collaboration/security suite. Users who already have email/collaboration elsewhere. No Exchange Online mailbox or full suite. Microsoft 365 Business Basic Business Basic is the lowest-cost complete Business suite in this guide. It provides a professional Exchange Online email service, OneDrive and SharePoint collaboration, and web/mobile versions of Word, Excel, PowerPoint and Outlook. The with-Teams SKU adds Teams meetings, chat and collaboration. It is a good fit for start-ups, contractors and browser-first employees who do not need locally installed Office applications. The limitation is not merely that Word runs in a browser. Basic does not include the integrated device management and endpoint threat protection found in Business Premium. Organizations using unmanaged laptops, handling sensitive client data or operating under customer security requirements should calculate the cost of separate controls before choosing Basic for everyone. Recommended size: usually 1–100 cloud-first users, although the formal Business-family ceiling is 300. Microsoft 365 Business Standard Business Standard is the natural productivity plan for employees who create documents and spreadsheets all day. It adds desktop versions of Word, Excel, PowerPoint and Outlook to the services in Basic, while keeping the familiar Exchange, OneDrive and SharePoint foundation. It is often the best functional fit for a 20–50 person office where endpoint security is already provided by another managed platform. Its weakness appears when buyers assume that “Microsoft 365” automatically means full Microsoft security. Standard does not deliver the same Intune, Entra ID P1 and Defender for Business package as Premium. If conditional access, centrally managed mobile devices, endpoint detection and response, or automated investigation are requirements, Premium can be cheaper and simpler than assembling separate products. Recommended size: 5–300 users with a defined external security/management approach. Microsoft 365 Business Premium Business Premium combines the productivity experience of Standard with the controls many small organizations now need by default. Microsoft Intune manages corporate and mobile devices; Microsoft Entra ID P1 supports conditional access; Microsoft Defender for Business adds endpoint protection, detection and response; and information-protection capabilities help reduce accidental data exposure. Premium is usually the strongest default for a security-first SMB, professional-services firm, healthcare supplier or company pursuing cyber-insurance and customer assurance requirements. It is not identical to Microsoft 365 E5 and does not remove the need for configuration, monitoring and governance. Its commercial boundary is the 300-user Business-family limit. Recommended size: 20–300 users, or smaller companies with high data or device risk. Microsoft 365 Apps for Business Apps for Business is not “Business Standard without meetings.” It is an app-focused subscription: desktop Office applications and OneDrive, without an Exchange Online business mailbox or the complete collaboration and security stack. It can be economical when email and meetings are supplied by another platform, or for a specialist user who needs Office locally but does not need the rest of the Microsoft 365 suite. The plan becomes poor value when separate email, Teams, identity and security licenses are added one by one. Buyers should also remember the 300-user Business-family ceiling and verify Copilot eligibility for the exact SKU. Recommended size: selected roles in organizations up to 300 users, not a universal default. Business Standard vs Business Premium Decision point Business Standard Business Premium Desktop Office apps Included Included Exchange, OneDrive, SharePoint Included Included Microsoft Intune Not included Included Microsoft Entra ID P1 / conditional access Not included as the suite entitlement Included Defender for Business Not included Included Best choice when Security and device management are provided elsewhere Microsoft should provide the integrated SMB security stack 2026 US list price with Teams $14 $22 The $8 monthly gap equals $96 per user per year. The right question is therefore not “Is Premium 57% more expensive?” but “Can we provide equivalent identity, device and endpoint controls for less than $96 per user per year—including administration?” Business plans vs Enterprise plans Business plans are not inferior versions of Enterprise in every respect. Business Premium can be a very capable security package for a 200-person company. Enterprise becomes necessary when the organization exceeds the 300-seat Business limit, needs enterprise Windows rights, requires deeper Purview, Defender or Entra capabilities, or wants a licensing framework designed for complex global operations. Choose Business when… Choose Enterprise when… The tenant will remain at or below 300 Business users. The organization will exceed the 300-user Business-family ceiling. Business Premium covers the required identity, device and endpoint controls. E3/E5 security, compliance, Windows or governance rights are required. Procurement and operations benefit from a compact SMB suite. Role-based licensing, enterprise agreements and global administration are central. Advanced eDiscovery, risk-based identity and enterprise analytics are not core requirements. Advanced Purview, Entra ID P2, Defender suite or Power BI capabilities justify E5. Enterprise plans: Office 365 E1, Microsoft 365 E3 and E5 This section intentionally compares the plans buyers most often place on the same shortlist. Office 365 E1 is a cloud-productivity plan. Microsoft 365 E3 and E5 are broader suites. If a seller quotes Office 365 E3 or E5 instead, check whether Windows Enterprise, Intune and the wider identity/security stack are included—the product name changes the entitlement. Office 365 E1 Office 365 E1 provides enterprise email, SharePoint, OneDrive and web/mobile Office experiences, with Teams in the applicable SKU. It does not include the full desktop Office client. E1 suits browser-first enterprise users, selected contractors or light information workers when Windows, device management and endpoint protection are licensed separately. At $10 with Teams, it is inexpensive, but it can create a fragmented stack if the missing controls are later added individually. Microsoft 365 E3 Microsoft 365 E3 is the enterprise foundation for managed knowledge workers. It combines desktop, web and mobile productivity apps with Exchange, SharePoint and OneDrive, then adds Windows Enterprise, Microsoft Intune, Microsoft Entra ID P1 and core security and compliance capabilities. Summer 2026 packaging additions include Defender for Office 365 Plan 1 and additional Intune tools, increasing its value for security and IT operations. E3 is a good fit for large organizations that require consistent device and identity management but do not need the full E5 control set for every user. It is also a common base license for the $30 enterprise Copilot add-on. Recommended size: enterprise-scale tenants and organizations approaching or exceeding the Business ceiling. Microsoft 365 E5 Microsoft 365 E5 builds on E3 with advanced identity, security, compliance, analytics and voice capabilities. Important areas include Microsoft Entra ID P2 features such as risk-based access and Privileged Identity Management, the broader Microsoft Defender suite, advanced Microsoft Purview capabilities, Power BI Pro and Teams Phone Standard in applicable offerings. Some telephony services, calling plans and deployment costs remain separate. E5 is most valuable where advanced controls replace multiple standalone products or address explicit regulatory and risk requirements. It is rarely necessary for every employee simply because the company is large. Many enterprises use E5 for administrators, executives, legal/compliance and high-risk roles while keeping E3 as the standard. Recommended size: regulated, security-mature or analytically intensive enterprises with a clear control map. Microsoft 365 E3 vs E5 Capability area Microsoft 365 E3 Microsoft 365 E5 2026 US list price with Teams $39 $60 Desktop apps and core cloud services Included Included Windows Enterprise, Intune, Entra ID P1 Included Included Advanced risk-based identity / PIM Limited compared with E5 Entra ID P2 capabilities Threat protection Strong foundation; expanded in 2026 Broader Defender suite and advanced controls Compliance Core information protection, audit and governance Advanced Purview, eDiscovery, audit and risk capabilities Analytics / voice Not the full E5 bundle Power BI Pro and Teams Phone Standard in applicable suite Best use Managed enterprise default High-risk, regulated and advanced-control roles The $21 monthly difference is $252 per user per year. A defensible E5 business case maps each required control to an E5 entitlement, identifies tools that can be retired, and assigns E5 only to the users whose work or risk needs it. Microsoft 365 Frontline: F1 vs F3 Frontline licenses are intended for people whose primary work is customer service, manufacturing, logistics, field operations or shift-based activity—not as a low-cost substitute for information-worker licenses. Microsoft applies eligibility and device-use conditions, so role design should be documented before procurement. Plan What it is designed to provide Main limitations / decision Microsoft 365 F1 — $3 Light frontline communication, identity and access, web/mobile experiences and core security/management services. Entra ID P1 and Intune are part of the frontline foundation. No full desktop Office suite. Mailbox and service functionality are limited; validate the exact frontline workflow and Exchange entitlement. Microsoft 365 F3 — $10 Broader frontline productivity, Windows and management rights, web/mobile apps and stronger support for shared/managed devices. Still not an E3 information-worker license and does not include full desktop Office apps. Confirm storage, mailbox, device and app requirements. Choose F1 for communication-led roles with very light creation needs. Choose F3 when workers use managed shared devices, need broader apps and workflow capabilities, or require Windows and device-management rights. Use E3/Business plans for employees who regularly create complex documents, use desktop Office or need a full information-worker mailbox and storage profile. Microsoft 365 Apps vs a full suite Need Apps for Business Business Standard Microsoft 365 E3 Desktop Word, Excel, PowerPoint, Outlook Yes Yes Yes Business email mailbox No Yes Yes SharePoint and full collaboration suite No / limited to included app services Yes Yes Integrated device and identity management No No Yes Windows Enterprise rights No No Yes User ceiling 300 Business-family users 300 Business-family users Enterprise scale Best fit Office apps alongside another platform Complete SMB productivity Managed enterprise workforce Security and compliance matrix “Included” does not mean “configured.” Every plan still needs secure defaults, role ownership, monitoring, retention decisions and user training. The matrix is a buying-level view, not a substitute for Microsoft’s detailed service descriptions and licensing terms. Plan Identity / access Device / endpoint Threat protection Compliance / governance Business Basic / Standard Foundational identity and MFA No integrated Intune entitlement Built-in service protection; 2026 URL protection Core Microsoft 365 controls Business Premium Entra ID P1; conditional access Intune + Defender for Business SMB endpoint detection/response and protection SMB information-protection capabilities Office 365 E1 Cloud identity foundation Not a broad device-management suite Foundational service protection Core cloud compliance Microsoft 365 E3 Entra ID P1 Intune + Windows Enterprise Enterprise foundation; Defender for Office P1 added in 2026 Core Purview, audit and information protection Microsoft 365 E5 Entra ID P2 / advanced identity Advanced enterprise management capabilities Broader Defender suite Advanced Purview, eDiscovery, audit and risk Microsoft 365 F1/F3 Entra ID P1 Intune; F3 supports broader frontline device use Frontline foundation; add-ons may be needed Role-appropriate baseline; validate regulation needs Microsoft 365 Copilot licensing in 2026 Copilot licensing has three distinct layers: Copilot Chat included with eligible subscriptions; a paid Microsoft 365 Copilot license that adds work-grounded and in-app experiences; and the eligible Microsoft 365 base license beneath it. Confusing these layers is the most common cause of an inaccurate budget. AI option 2026 price / eligibility What it does Best use Microsoft 365 Copilot Chat No additional license cost with eligible Microsoft 365 subscriptions. Agent consumption may be metered. Secure AI chat, primarily web-grounded; can work with referenced/uploaded content and selected agents. Broad baseline for occasional AI use. Microsoft 365 Copilot Business $21 list; 2026 promotional price may be $18. Eligible Business plans; up to 300 users. Work-grounded Copilot in Microsoft 365 apps, using data the user can access through Microsoft Graph and Work IQ. SMBs with selected high-value knowledge workers. Microsoft 365 Copilot (enterprise) $30 per user/month, annual commitment. Requires an eligible base plan. Paid work-grounded Copilot across Word, Excel, PowerPoint, Outlook, Teams and other supported experiences. Enterprise, Office 365 and Frontline base-license environments. Business plan with Copilot July 2026 US list: Standard with Copilot $23.50; Premium with Copilot $32. Annual/annual and up to 300 users. Base Business suite and Copilot in one SKU. Often cheaper than buying the base plan and Copilot Business separately. Microsoft 365 E7 $99 with Teams / $90.45 without Teams. M365 E5 plus Microsoft 365 Copilot, Agent 365 and Entra Suite. Enterprises that need the broader bundle—not merely Copilot. Copilot Chat vs paid Microsoft 365 Copilot Capability Copilot Chat Paid Microsoft 365 Copilot Additional per-user license No, with eligible subscription Yes, unless included in a bundle Default grounding Primarily web and user-provided context Work data plus web, subject to permissions Microsoft Graph / Work IQ context Limited compared with paid offer Core part of the work-grounded experience In-app assistance Selected chat/agent experiences Deeper Word, Excel, PowerPoint, Outlook and Teams integration Agents Available; tenant-data use may be consumption-metered Broader included agent value; metering can still apply to some scenarios Best rollout role All eligible users as a controlled baseline Selected users with measurable knowledge-work use cases Copilot does not receive unrestricted access to a tenant. Microsoft states that it can use only information the signed-in user is authorized to access, and prompts, responses and Microsoft Graph data are not used to train the foundation models. That protection makes permission hygiene more—not less—important. An overshared SharePoint site remains overshared; Copilot can make existing access easier to exercise. How to calculate the total cost A reliable budget has four lines: the base Microsoft 365 license, the Copilot license or bundle, the billing/term effect, and implementation. Implementation includes tenant assessment, permission cleanup, device onboarding, migration, training, adoption management and support. Those services are not Microsoft license fees, but omitting them produces a misleading business case. Scenario Monthly list calculation Annual list total 50 users: Business Premium 50 × $22 $13,200 50 users: Business Premium with Copilot 50 × $32 $19,200 100 users: Business Standard + separate Copilot Business 100 × ($14 + $21) $42,000 100 users: Business Standard with Copilot bundle 100 × $23.50 $28,200 500 users: Microsoft 365 E3 500 × $39 $234,000 500 E3 users; Copilot for 100 selected users (500 × $39) + (100 × $30) $270,000 500 E3 users; Copilot for everyone 500 × ($39 + $30) $414,000 The 100-user example shows why SKU comparison matters: the permanent Business Standard with Copilot bundle can be materially cheaper than two separate licenses. Promotions and bundles change, however, so every quote should state the exact SKU, commitment, payment schedule, promotion end date and renewal price. Which license is best by company size? Organization / workforce Recommended starting point Why / what to validate Micro business: 1–10 Basic for browser-first roles; Standard for desktop users; Premium if devices/data are high risk. Avoid buying one plan for everyone by habit. Check whether separate security products erase Basic/Standard savings. Small company: 20–50 Business Premium as a security-led default; mix Standard or Basic for justified lower-risk roles. Strong balance of productivity and integrated controls. Compare Copilot bundle for selected users. Midsize: 100–300 Business Premium or role-based Business mix; plan the path beyond 300 early. Govern tenant growth and avoid a rushed enterprise migration at user 301. Enterprise: 300+ Microsoft 365 E3 default; E5 for mapped advanced-control roles; F1/F3 for true frontline workers. Use role/risk segmentation and enterprise procurement. Regulated organization E3 plus required add-ons or E5 for roles subject to advanced compliance, identity and investigation needs. Map regulation to controls; regulation alone does not automatically require E5 for everyone. Security-first SMB Business Premium. Intune, Entra ID P1 and Defender for Business create a coherent baseline. Six practical licensing scenarios 1. A seven-person consultancy Five consultants need desktop Office and two contractors work in the browser. Use Business Standard for the consultants and Business Basic for the contractors if devices are already managed and protected. If client requirements demand conditional access and managed endpoints, Business Premium may be the simpler standard. Add Copilot only to consultants who repeatedly draft proposals, summarize meetings or analyze client material. 2. A 35-person professional-services firm Business Premium is usually the strongest baseline because confidential client data, remote laptops and cyber-insurance controls make identity and device management central. Compare Business Premium with Copilot for partners, sales and delivery leads against separate Copilot Business seats. Keep Copilot Chat available to eligible non-licensed employees. 3. A 220-person growing company A role-based Business mix can remain cost-effective: Premium for managed employees, Standard for specific low-risk desktop roles and Basic for browser-only accounts. Track the tenant’s Business-family count and design the move to E3 before growth crosses 300. A 20–40 user Copilot pilot is safer than a company-wide purchase. 4. A 2,000-person enterprise Use E3 as the managed knowledge-worker foundation, E5 for administrators, legal, security, executives and regulated roles, and F1/F3 for properly eligible frontline workers. Add enterprise Copilot only to roles with repeatable work-grounded use cases, then review Microsoft’s usage report and reassign inactive seats. 5. A regulated financial or healthcare organization Start from the control requirements: identity risk, privileged access, information classification, retention, audit, eDiscovery, insider risk, endpoint coverage and incident response. E5 may consolidate necessary controls, but assigning it universally without a control-to-license map wastes budget. Copilot readiness must include permissions, sensitivity labels, retention and high-risk repositories. 6. A factory with shared frontline devices F3 is often the practical foundation for supervisors and workers using managed shared devices and digital workflows; F1 may suit communication-led roles. Information workers in finance, engineering or management should remain on E3 or appropriate Business plans. Do not use frontline SKUs solely because they cost less—the worker and device scenario must satisfy licensing rules. Can Microsoft 365 licenses be mixed? Yes. A tenant can combine Business plans, Enterprise plans, Frontline plans and paid Copilot assignments, subject to eligibility and commercial terms. Mixing works best when every role has a written service profile: desktop apps, mailbox, storage, meeting needs, device type, identity risk, information sensitivity and AI use case. It works badly when procurement chooses exceptions without governance, leaving IT to discover missing services later. Review dependencies before changing a license. Removing a suite can remove access to a mailbox, desktop activation, Windows rights, Intune policies or compliance capabilities. Data retention and service behavior should be validated before reassignment—not after a user reports that an app stopped working. A practical selection and rollout process Inventory users and devices: Group people by real work patterns, not department names. Separate knowledge workers, browser-first users, contractors, frontline workers, privileged admins and regulated roles. Define mandatory controls: List identity, device, endpoint, data protection, retention, audit, eDiscovery and residency requirements. Map each control to a license entitlement and configuration owner. Compare complete stacks: Compare the suite price with all necessary add-ons, third-party tools and administration. A cheaper base plan is not cheaper if it creates three extra contracts. Check Teams and billing variants: Confirm with-Teams or no-Teams SKU, annual versus monthly commitment, payment schedule, currency, tax, promotion expiry and renewal price. Pilot Copilot by workflow: Choose three to five measurable workflows such as meeting follow-up, proposal drafting, inbox triage, report synthesis or recurring analysis. Measure and reassign: Track active users, repeat use, adoption by app, task time, quality and rework. Reassign licenses that remain inactive after support and training. Common licensing mistakes to avoid Comparing Office 365 E3 with Microsoft 365 E3 as if the names described the same entitlement. Buying Business Standard and later discovering that conditional access, Intune and endpoint detection were expected. Using F1/F3 as generic discount licenses for users who are not genuine frontline workers. Treating a no-Teams price as interchangeable with the with-Teams SKU without checking the meeting and collaboration requirement. Multiplying the Copilot price by headcount without adding the eligible base license—or without checking a cheaper bundle. Assuming Copilot fixes poor permissions. It follows the access the user already has. Using a temporary promotion as the long-term renewal run rate. Licensing the entire tenant before measuring a small, role-based pilot. TTMS: a trusted Microsoft 365 partner Microsoft 365 licensing is easiest to optimize when commercial choices, technical design, security and adoption are treated as one program. TTMS supports organizations across the Microsoft 365 lifecycle: environment assessment, migration, license rationalization, security preparation, employee training, Teams solutions and process automation with Power Automate and Power Apps. An experienced partner adds value before the order is placed. TTMS can help map user roles to Business, Enterprise and Frontline plans; compare bundles with add-ons; identify licensing gaps; assess data and permission readiness for Copilot; and build a phased rollout with measurable outcomes. This reduces both overspending and the operational risk of choosing a plan that looks right on a price list but does not cover the organization’s controls. If you want to review your current license mix, plan a migration or prepare a Microsoft 365 Copilot pilot, talk to the TTMS Microsoft 365 team about the next practical step for your organization. Sources and verification note Pricing and licensing were checked against official Microsoft sources on August 6, 2026. Microsoft can change products, promotions and local prices. Detailed service availability also contains footnotes and technical conditions, so the final SKU and entitlement should be verified in the Microsoft 365 admin center, product terms or a current partner quote. This guide is commercial and technical guidance, not legal advice. Microsoft 365 pricing and packaging updates effective July 1, 2026 Microsoft 365 pricing and packaging update FAQ Microsoft 365 and Office 365 plan options Microsoft 365 platform service description Business plan comparison reference Enterprise plan comparison reference Frontline F1 and F3 comparison Microsoft Entra service description Microsoft 365 Copilot plans and pricing Microsoft 365 Copilot license options Microsoft 365 Copilot architecture and permissions Microsoft 365 Copilot usage report TTMS Microsoft 365 services Frequently Asked Questions About Microsoft 365 Licensing and Copilot What is the cheapest Microsoft 365 license for a business? Among the complete Business suites in this guide, Business Basic is the lowest-cost at $7 per user per month with Teams in the July 2026 US list price. Apps for Business costs $10 but does not include a business mailbox or the full collaboration suite. The cheapest suitable plan depends on whether the user needs desktop apps, email, device management and security—not price alone. What is the difference between Microsoft 365 Business Premium and Microsoft 365 E3? Business Premium is a strong integrated productivity and security suite for organizations with up to 300 Business users. Microsoft 365 E3 is an enterprise-scale suite with Windows Enterprise, Intune, Entra ID P1 and broader enterprise rights and governance. E3 is not automatically “more secure” in every practical configuration; the choice depends on scale, entitlements and required controls. Is Microsoft 365 Copilot included in Microsoft 365? Copilot Chat is included at no additional license cost with eligible Microsoft 365 subscriptions. Full work-grounded Microsoft 365 Copilot normally requires a paid add-on, unless it is included in a bundle such as Business Standard with Copilot, Business Premium with Copilot or Microsoft 365 E7. Which Microsoft 365 plan is best for a 50-person company? Business Premium is often the best security-led default because it combines desktop apps, email, collaboration, Intune, Entra ID P1 and Defender for Business. A company with mature third-party device and endpoint security may prefer a mix of Standard and Basic. The correct answer follows the control and device requirements. Can a company mix Microsoft 365 licenses? Yes. Organizations commonly mix Basic, Standard, Premium, Enterprise and Frontline plans and assign paid Copilot only to selected users. Each user must have the services and rights required for their role, and dependencies should be checked before a license is removed or changed. When should a company move from Business to Enterprise licensing? Plan the move when the tenant approaches the 300-user Business-family ceiling or when Windows Enterprise, advanced compliance, identity, security, procurement or global-management needs exceed the Business suite. Do not wait until user 301 to design the transition. Does Microsoft 365 Business Basic include desktop Word and Excel? No. It includes web and mobile versions. Choose Business Standard or Premium when users need locally installed desktop Office applications. What is the difference between Office 365 E1 and Microsoft 365 E3? Office 365 E1 is primarily a cloud-productivity suite with web/mobile apps and no full desktop Office client. Microsoft 365 E3 combines desktop productivity with Windows Enterprise, Intune, Entra ID P1 and broader security and compliance capabilities. They are different product families, not adjacent tiers of the same bundle. Is Microsoft 365 E5 worth the extra cost over E3? E5 is worth it when its advanced identity, Defender, Purview, analytics or voice capabilities replace other products or meet explicit risk and regulatory requirements. Many organizations assign E5 only to selected high-risk roles and use E3 as the wider default. What is the difference between Microsoft 365 F1 and F3? F1 is a lighter frontline license for communication-led roles. F3 supports broader frontline productivity, Windows and managed-device scenarios. Neither should be treated as a discount E3 license, and both require validation of frontline eligibility and service limitations. Can Microsoft 365 Apps for Business replace Business Standard? Only if the user does not need Exchange Online business email or the full Microsoft 365 collaboration suite. Apps for Business is best when desktop Office and OneDrive are needed alongside another email/collaboration platform. How much does paid Microsoft 365 Copilot cost? The enterprise Microsoft 365 Copilot add-on is $30 per user per month with an annual commitment. Copilot Business lists at $21 and has had an $18 promotional price in 2026. Permanent Business bundles listed in July 2026 include Business Standard with Copilot at $23.50 and Business Premium with Copilot at $32. Verify current local pricing and renewal terms. What is the difference between Copilot Chat and paid Microsoft 365 Copilot? Copilot Chat is primarily a secure web-grounded chat experience included with eligible subscriptions. Paid Copilot adds work grounding and deeper integration in Microsoft 365 apps, using information the signed-in user is permitted to access through Microsoft Graph and Work IQ. Does every employee need a paid Copilot license? No. Copilot Chat can serve as the broad baseline, while paid seats go to roles with repeatable writing, meeting, analysis or information-search workflows. A phased pilot and license reassignment process usually produces a better return than tenant-wide licensing. Does Copilot use company data to train foundation models? Microsoft states that prompts, responses and organizational data accessed through Microsoft Graph are not used to train the foundation models used by Microsoft 365 Copilot. Copilot still follows existing user permissions, so overshared data and weak governance must be addressed. Are annual Microsoft 365 subscriptions cheaper than monthly subscriptions? Annual commitments are usually priced more favorably than flexible month-to-month terms, but payment monthly and commitment monthly are not the same thing. Ask for the term, payment frequency, cancellation conditions and renewal price on every quote.
Read
NIS2 Cybersecurity in Pharma Requirements, Obligations,and Implementation in 2026
NIS2 cybersecurity in pharma is an operational resilience requirement, not a stand-alone IT project. A cyber incident can stop a filling line, isolate a laboratory, interrupt a cold chain, corrupt a clinical dataset or make a validated system unavailable. Each outcome can affect product quality, patient safety and continuity of supply. Directive (EU) 2022/2555, known as NIS2, creates a common EU baseline for cybersecurity risk management, management oversight and significant-incident reporting. The legal duty is implemented through national law. A company must therefore read the Directive together with the rules, thresholds, registration procedures and competent-authority guidance in every Member State where it falls within scope. This guide converts the legal baseline into actions and evidence for pharmaceutical manufacturers, biotechnology companies, medicinal-product R&D organisations, contract manufacturing organisations (CMOs), contract research organisations (CROs) and their critical suppliers. It also explains where NIS2 must be aligned with GxP, Computerized System Validation (CSV), Computer Software Assurance (CSA), GAMP 5 and existing quality-management processes. This article covers pharma-specific implementation. For the detailed evidence model, see the TTMS NIS2 compliance documentation and evidence checklist. 1. Why pharmaceutical operations are a priority cyber target under NIS2 NIS2 places the manufacture of basic pharmaceutical products and pharmaceutical preparations within the health sector in Annex I, alongside healthcare providers, EU reference laboratories and entities carrying out research and development of medicinal products. That classification reflects systemic impact: disruption can affect access to medicines and public-health response, not only one company’s balance sheet. The threat picture supports that treatment. ENISA reported that, among health-related incidents analysed for its 2024 threat landscape, 45% involved ransomware and 28% involved data breaches. A separate commercial dataset counted 4,198 ransomware cases exposed on dark-web leak sites across all sectors in the first half of 2025, 49% more than in the comparable 2024 dataset. The 4,198 figure is not pharma-specific, so it should not be presented as a count of attacks on pharmaceutical or biotechnology organisations. Pharma combines assets that create leverage for attackers: intellectual property, clinical and patient-related data, regulated production, scarce batches, time-sensitive logistics and a broad supplier network. The same identity platform, integration layer or remote-maintenance channel may connect corporate IT with ERP, MES, LIMS, ELN, EDC and operational technology (OT). An attacker does not need to compromise every system. Disrupting one shared dependency may be enough to stop release, testing or distribution. Treat the business impact as a chain. Map each critical product or service to facilities, processes, systems, data, utilities, people and third parties. Record the maximum tolerable outage and the quality consequences of data loss or delayed review. That service map becomes evidence for risk analysis, business continuity, recovery priorities and supply-chain decisions. 2. NIS2 in life sciences: scope, classification and legal status NIS2 expanded the EU cybersecurity baseline beyond the narrower NIS1 model. It applies, as a rule, to medium-sized and large entities of a type listed in Annex I or Annex II, subject to specific inclusions and exceptions. In life sciences, the legal analysis must start with what the entity actually does—not the brand description “pharma”, “biotech” or “healthcare”. Activities may include medicinal-product R&D, API or finished-product manufacture, device manufacture, clinical operations, distribution, marketing, digital services or combinations of them. A group can contain entities with different statuses. A CMO or CRO is not automatically in or out merely because of its label. The relevant activity, size, establishment, jurisdiction and any national designation must be documented. 2.1 From NIS1 to NIS2: what changed for health and pharma NIS2 widens sector coverage, standardises a minimum set of cybersecurity risk-management measures, sets a staged significant-incident reporting model and strengthens supervision and enforcement. It requires management bodies to approve risk-management measures, oversee implementation and receive training. It also requires Member States to maintain national cybersecurity strategies and incident-response structures. The result is a common baseline, not identical administration across the EU. Registration, thresholds, forms, competent authorities, language, audit expectations and sanctions are implemented nationally. In July 2026, the Commission referred Ireland, Spain, France and the Netherlands to the Court of Justice for failing to notify full transposition. Cross-border groups still need a jurisdiction register and local legal verification. Existing GMP and quality-management governance can provide a starting structure. Management review, change control, deviation management, CAPA, supplier qualification, training and periodic review already create owners and records. Extend those processes to cybersecurity; do not assume that GxP evidence automatically proves NIS2 compliance. 2.2 Essential or important entity? Classify before selecting controls Under Article 3, an Annex I entity that exceeds the ceiling for a medium-sized enterprise is generally an essential entity. Other medium-sized entities within Annex I or Annex II are generally important entities, unless a specific rule or national designation changes the result. Certain entity types are essential regardless of size. Micro and small enterprises are generally excluded, but Article 2 contains exceptions based on criticality and other factors. Pure distribution or marketing activity may fall outside the listed pharma categories when the entity performs no covered activity and is not designated on another basis. Conversely, an organisation conducting medicinal-product R&D can fall within Annex I even if it does not manufacture. Medical-device coverage also requires careful reading of the relevant Annex category; not every device business has the same classification. Create a signed scope memorandum for each legal entity. Include activities, NACE or equivalent classification, headcount and financial data, establishments, services, national rules, group dependencies and the reason for the conclusion. Record who approved it and when it must be reviewed. This memorandum is the first auditable artefact; a product brochure or a group-level assumption is not enough. 3. Four compliance pillars for pharmaceutical organisations Organise NIS2 around four connected pillars: risk management, significant-incident reporting, management accountability and supply-chain security. Each needs an owner, a procedure and operating evidence. 3.1 Article 21 risk management: ten minimum areas Article 21 requires appropriate and proportionate technical, operational and organisational measures based on an all-hazards approach. The ten minimum areas below should be mapped to services and risks, not treated as a generic tool-purchasing list. Article 21 area Pharma implementation focus Typical audit evidence 1. Risk analysis and information-system security policies Link product, patient and service impact to IT, OT and GxP systems Approved method, service map, risk register, treatment decisions 2. Incident handling Coordinate security, quality, privacy, legal, production and communications Incident plan, severity matrix, case records, after-action reports 3. Business continuity, backup, disaster recovery and crisis management Prioritise batch, laboratory, release and cold-chain dependencies BIA, RTO/RPO, recovery plans, restore tests, exercise reports 4. Supply-chain security Assess API, CMO, CRO, logistics, cloud and maintenance dependencies Supplier tiering, due diligence, contracts, monitoring, exit plans 5. Secure acquisition, development and maintenance, including vulnerability handling and disclosure Connect security changes to validated-state and change-control decisions Security requirements, threat models, vulnerability records, change packages 6. Assessment of control effectiveness Test design, coverage and operating results Control tests, metrics, internal audits, CAPA and closure evidence 7. Cyber hygiene and training Train by role, including engineers, laboratory staff and management Curricula, attendance, competence checks, phishing or exercise results 8. Cryptography and encryption Protect data and communications while managing keys and certificates Cryptography standard, key inventory, certificate monitoring, exceptions 9. HR security, access control and asset management Control joiners, movers, leavers, privileged access and system ownership Asset register, access reviews, PAM records, segregation-of-duties evidence 10. MFA or continuous authentication and secure communications Cover remote access, privileged actions and exposed services based on risk MFA coverage, exception register, secure-channel configuration and reviews Build requirements traceability between each NIS2 measure, the service risk, the control, the system owner and the evidence source. Existing GxP processes can carry part of the load. Vulnerability remediation can use change control; control testing can align with periodic review and CSA; security training can use the controlled learning system. The mapping must also expose gaps. A validated application with no tested recovery process remains a continuity risk. 3.2 Article 23 reporting: 24 hours, 72 hours and one month For a significant incident, Article 23 establishes staged reporting: an early warning without undue delay and within 24 hours after becoming aware; an incident notification without undue delay and within 72 hours; and a final report no later than one month after the incident notification. Intermediate or progress reports may also be required. If the incident is ongoing at the one-month point, a progress report replaces the final report and the final report follows within one month after handling ends. The clock starts from awareness, not from completion of a forensic investigation. Define who can declare awareness, who assesses significance, who contacts the national CSIRT or competent authority and who coordinates parallel duties under GDPR, sector rules, contracts and, where relevant, medical-device obligations. Preserve both the decision to report and a reasoned decision not to report. Real-time visibility across identity, network, endpoint, cloud, ERP, MES, LIMS, ELN, EDC and OT improves the chance of meeting the timetable. A central SIEM can support detection and chronology, but it does not make a legal significance assessment. Use a human-in-the-loop process with on-call authority, a current contact list, pre-approved templates and a decision log. In validated environments, deploy monitoring through approved change control. Passive OT monitoring, network telemetry and controlled log forwarding may reduce interference with production assets. Test the entire route in a tabletop exercise: alert, technical triage, quality impact, legal assessment, management escalation, authority submission and follow-up. 3.3 Article 20: management responsibility and board-level evidence Management bodies must approve the Article 21 measures, oversee implementation and can be held liable for infringements under national law. Members must follow training, and Member States must encourage regular training for employees. Evidence should show informed oversight, not a ceremonial annual presentation. Provide the board with decisions it can act on: top service risks, overdue high-risk treatments, control effectiveness, significant incidents, recovery-test failures, critical supplier exposure, material exceptions and required investment. Retain agendas, papers, minutes, approvals, challenge and follow-up. Record training content, attendance and an effectiveness check. The Directive also allows competent authorities, in specified circumstances concerning essential entities, to request temporary suspension of a certification or authorisation and a temporary prohibition on certain senior managers exercising managerial functions until deficiencies are remedied. This is a supervisory measure with conditions, not an automatic personal ban after every incident. Avoid overstating it as criminal liability. 3.4 Article 21(2)(d): API, CMO, CRO and logistics risk Map suppliers to the services and products they can affect. Include API and excipient suppliers, CMOs, CROs, testing laboratories, packaging, cold-chain logistics, cloud platforms, managed services, equipment vendors, remote maintenance and single-source technology dependencies. Tier suppliers using impact, access, substitutability, concentration and recovery time. Due diligence should test the evidence relevant to the service: control scope, incident history, privileged access, subcontractors, vulnerability handling, backup and recovery, secure development, geographic concentration and exit feasibility. A questionnaire is a declaration; a certificate has value only after its scope, exclusions and period are checked. Contracts should define minimum controls, incident-notification timing, cooperation, audit or assurance rights, vulnerability handling, subcontractor conditions, data return, continuity and exit. Contract language does not replace monitoring. Record reviews, adverse findings, risk acceptance, compensating controls, owners and expiry dates. 4. Pharma-specific cybersecurity challenges NIS2 does not solve by itself NIS2 states outcomes and minimum risk areas. It does not prescribe how to patch a validated MES, monitor a PLC in a clean manufacturing area or preserve ALCOA+ principles during a cyber response. These decisions require security, quality, engineering and regulatory roles to work from one risk record. 4.1 Secure validated systems without losing validated state A security patch or configuration change can affect the validated state of MES, LIMS, QMS, chromatography, environmental-monitoring or other GxP systems. Delaying every patch is unsafe; applying every patch without assessment is also unsafe. The control objective is a documented, risk-based decision. Connect vulnerability management to change control. Record asset and version, vulnerability severity, exploitability, patient or product impact, exposure, vendor support, proposed change, test scope, rollback, compensating controls and approval. Use GAMP 5 and CSV or CSA principles to scale assurance to the risk of the changed function. Re-test what can affect intended use, data integrity, electronic records, interfaces and critical calculations. Maintain validated state throughout the lifecycle. Periodic review should reconcile configuration, deviations, patches, access, backup, audit trails, incidents and supplier changes. Emergency changes need predefined authority and retrospective quality review. Evidence should make the sequence traceable from threat to decision, test, release and post-implementation monitoring. 4.2 Protect clinical-trial data, IP and patient-related information NIS2 covers entities carrying out R&D activities of medicinal products when the scope and size rules are met. Their risk model must protect availability, authenticity, integrity and confidentiality across protocol design, investigator sites, eCOA, EDC, safety systems, biostatistics, regulatory submissions and partner exchanges. Apply ALCOA+ data-integrity thinking: records should remain attributable, legible, contemporaneous, original, accurate, complete, consistent, enduring and available. Cyber controls must protect the audit trail and the context required to interpret data. Detect bulk data exports, unusual privileged activity, manipulation and unauthorised interface changes. Test restoration of both data and metadata. Privacy belongs in a coordinated but distinct assessment. A single event can create a NIS2 significant-incident question and a GDPR personal-data-breach question with different tests, recipients and deadlines. Maintain one fact base and timeline, then run separate legal decision paths. 4.3 IT/OT convergence in manufacturing and clean areas OT assets often have long lifecycles, vendor constraints, deterministic communications and limited maintenance windows. Standard endpoint agents may be unsupported. A production pause can itself create quality and supply consequences. Treat OT as a distinct engineering risk domain connected to enterprise governance. Begin with passive discovery and verified ownership. Define zones and conduits, restrict remote access, separate safety and control functions from business networks, protect engineering workstations, monitor allowed communications and control removable media. Use compensating controls when patching is not feasible. Confirm that segmentation and fail-safe behaviour do not disrupt real-time control or environmental conditions. Every change should have cyber, automation and quality acceptance criteria. Test during approved windows, document rollback and retain configuration baselines. The evidence package should include current diagrams, firewall rules, remote-access reviews, alert handling, backup or configuration-restore tests and approved exceptions. 5. NIS2, GDPR, MDR and quality systems: one management model NIS2 protects the resilience and security of network and information systems. GDPR protects personal data and creates breach-notification duties. MDR and IVDR govern medical devices and include safety, quality and post-market obligations. GMP and GxP govern product quality and data integrity. One incident can activate several regimes, but the legal tests are not interchangeable. Build one management model with multiple compliance mappings. Use a common service catalogue, asset register, risk method, incident record, supplier register, training process, CAPA workflow and evidence index. Map each control to the applicable NIS2 article, national law, GDPR requirement, quality procedure and device obligation. This reduces duplicate evidence without collapsing distinct decisions. Create a regulatory decision matrix before an incident occurs. For each regime, record the trigger, decision owner, recipient, deadline, minimum content and rule for follow-up. Add contractual notifications and communications to investigators, insurers, partners and affected customers. During an incident, one coordination lead should maintain the verified facts, while qualified owners make the separate legal and quality decisions. This model reduces contradictory reporting without allowing the shortest deadline to erase the distinct tests applied by each regime. ISO/IEC 27001 can provide a useful information-security management structure; it does not by itself prove NIS2 scope, registration or national reporting compliance. ISO/IEC 42001 can support governance where AI is used in LIMS analytics, quality review or security operations, but AI controls still require validation, data-integrity assessment and human oversight appropriate to the use case. Design an integrated incident form with separate sections for service impact, product and patient impact, personal data, regulatory status, notification decisions and communications. The same verified timeline can support the CSIRT, data-protection authority, quality unit and management without creating contradictory versions. 6. Penalties and enforcement: the cost of non-compliance Article 34 requires Member States to provide maximum administrative fines for essential entities of at least EUR 10 million or at least 2% of worldwide annual turnover in the preceding financial year, whichever is higher. For important entities, the corresponding levels are at least EUR 7 million or 1.4%, whichever is higher. National law determines the applicable enforcement process and may set higher maximums or additional measures. Fines are only one exposure. A cyber incident can generate lost sales, scrapped batches, delayed trials, recovery costs, contractual claims, privacy consequences and loss of confidence. Merck reported that its 2017 network attack disrupted manufacturing, research and sales, reduced 2017 sales by approximately USD 260 million and generated USD 285 million of manufacturing and remediation expense net of stated insurance recoveries; residual backlog affected 2018 sales by approximately USD 150 million. Do not justify controls only by comparing programme cost with the statutory maximum. Prioritise by service impact, credible threat, control weakness and legal duty. The board should see both compliance exposure and the operational loss scenario for each critical product or service. 7. A 9-12 month NIS2 implementation roadmap for pharma A 9-12 month programme can organise remediation, but it is not a legal grace period. Organisations already subject to national implementing law must meet current duties while improving maturity. Sequence work around critical risk and approved change windows in validated environments. 7.1 Step 1: scope and gap analysis Confirm each legal entity’s status and jurisdiction. Inventory critical services and products, then map IT, OT, laboratory, clinical, data, facility, people and supplier dependencies. Assess the ten Article 21 areas and national obligations. The assessment should produce an approved scope memorandum, jurisdiction register, service and dependency map, asset baseline, gap report, risk-ranked remediation plan and evidence index. Escalate any unknown externally exposed asset or unsupported critical system immediately. 7.2 Step 2: governance and accountability Assign executive sponsorship, service owners, control owners and an incident-reporting authority. Define RACI across security, IT, OT, engineering, quality, privacy, legal, procurement, HR, communications and business continuity. At this stage, the organisation should have a governance charter, RACI, management reporting pack, risk-acceptance thresholds, training plan, CSIRT contact matrix and defined authority for isolating production or laboratory systems. 7.3 Step 3: technical and organisational controls Prioritise identity, privileged access, MFA, network segmentation, secure remote access, EDR where supported, passive OT monitoring, central logging, vulnerability management, protected backups and recovery. Connect each change to quality and validation procedures. Completion is evidenced by approved architectures, control requirements, implementation records, validation or assurance evidence, coverage metrics, an exception register and tested rollback. Measure the population covered, not only whether a tool was purchased. 7.4 Step 4: supplier verification and continuous monitoring Tier API, CMO, CRO, laboratory, logistics, cloud, software and maintenance suppliers. Run due diligence proportional to access and impact. Remediate contracts and establish monitoring triggers. The operational output is a maintained supplier register supported by a criticality model, evidence reviews, risk decisions, security clauses, incident contacts, a monitoring schedule, concentration analysis and exit plans. Reassess after a material change or incident. 7.5 Step 5: build and test incident response Create playbooks for ransomware, data exfiltration, validated-system compromise, OT disruption, supplier incident and loss of a critical cloud service. Include quality and regulatory decisions, not only technical containment. The response capability should be documented in an incident plan, 24/72-hour and final-report templates, a significance assessment, an evidence-preservation method and a tabletop report. Run the exercise with executives and on-call personnel. Track corrective actions to verified closure. 7.6 Step 6: document, audit and sustain Convert control operation into evidence by design. Automate controlled reports where practical, identify record owners and set retention based on national law, sector duties, investigation needs and risk. Review the programme after incidents, major changes and legal updates. The programme closes with a controlled policy set, evidence index, management minutes, training records, incident and supplier files, recovery-test results, effectiveness testing, an internal-audit report and a CAPA register. Independent review should confirm closure of high-risk findings. 8. Documented cyber incidents: practical NIS2 lessons Public incident reports rarely prove which internal control failed. Use them to test plausible scenarios, not to accuse an organisation of a control deficiency that has not been established. Merck’s 2017 attack demonstrates that enterprise malware can reach manufacturing, research, sales and fulfilment at the same time. The NIS2 lesson is to map shared dependencies, segment environments, protect recovery capabilities and quantify product-level continuity. Exercise the decision to isolate a plant system when isolation may interrupt production. The 2020 cyberattack on the European Medicines Agency unlawfully accessed documents related to COVID-19 medicines and vaccines. EMA reported that some leaked material, including correspondence, had been manipulated before publication. The lesson is broader than confidentiality: protect authenticity, integrity and provenance across regulator and partner exchanges, and prepare communications for manipulated or incomplete data. Cencora disclosed in February 2024 that data had been exfiltrated from its information systems and might contain personal information. It stated at the time that operations remained functional and that containment, investigation, law-enforcement engagement and external support had begun. The lesson is to maintain rapid cross-functional triage even when availability is not affected: exfiltration can still trigger NIS2, privacy, contractual and trust decisions. For each scenario, retain the alert timeline, affected services, evidence sources, quality assessment, reporting decision, management escalation and corrective actions. Link lessons to Article 21 controls and test whether the same evidence could support the 24-hour early warning. 9. Selecting expert support for NIS2 implementation A pharma NIS2 partner must combine cybersecurity, regulated quality and implementation capability. Ask for evidence that the team can classify scope, map services, design IT/OT controls, manage validated change, build CSV or CSA evidence, assess suppliers, run incident exercises and explain residual risk to management. Evaluate the delivery model. A one-time gap report does not sustain compliance. Managed services can operate monitoring, vulnerability triage, evidence collection and supplier review, but accountability remains with the regulated organisation and its management. Define ownership, escalation, service levels, evidence access and exit from the start. Request sample deliverables before selection: a redacted scope memorandum, an Article 21 traceability matrix, a validated change package, an OT risk assessment, a supplier finding and an executive incident exercise report. Check whether conclusions identify assumptions, evidence and residual risk. Confirm that security specialists can work with quality, automation and legal teams, and that records can be transferred into the organisation’s controlled repositories. The partner should leave the organisation with an operating process and usable evidence, not a slide deck that cannot be maintained. TTMS combines an ISO/IEC 27001 information-security management environment with pharmaceutical computerized-system validation services aligned to GAMP 5 and Annex 11. Its published quality offering covers CSV and CSA across the system lifecycle. In February 2026, TTMS reported becoming the first Polish company to obtain accredited ISO/IEC 42001 certification for its AI management system after an audit by TÜV Nord Poland. These credentials are relevant where cyber controls, validated systems and governed AI must remain auditable in one operating model. To arrange a scoping call focused on legal entities, regulated services, critical products, validated systems, OT dependencies and current evidence, contact TTMS. The first output should be a defensible scope and prioritised action plan—not a generic control catalogue. 10. Frequently asked questions about NIS2 cybersecurity in pharma Does NIS2 apply to every pharmaceutical company? No. Scope depends on activity, size, establishment, national law and designation. Manufacturing and medicinal-product R&D are listed; marketing or distribution alone may lead to a different result. Document the conclusion for each legal entity. Is every pharmaceutical manufacturer an essential entity? No. Annex I classification does not automatically make every manufacturer essential. Size thresholds, Article 3 rules, exceptions and national decisions determine whether an organisation is essential, important or outside scope. Group companies may reach different conclusions. What are the main NIS2 incident-reporting deadlines? For a significant incident, the Directive sets an early warning within 24 hours of awareness, an incident notification within 72 hours and a final report within one month. National procedures and parallel duties under GDPR or sector rules must also be checked. How do NIS2, GxP and Annex 11 interact in pharmaceutical environments? NIS2 governs cyber risk and resilience; GxP and Annex 11 govern product quality, data integrity and computerized systems. Use one risk and change-control model while preserving separate legal assessments and validation evidence for security changes. How should security patches be handled in validated GxP systems? Route the vulnerability through risk assessment and controlled change. Document exploitability, product or patient impact, test scope, rollback and compensating controls. Apply CSV or CSA assurance proportionate to the affected function and retain traceability from the vulnerability to approval and post-change review.
Read
NIS2 Compliance Documentation: What Evidence Should Businesses Prepare?
NIS2 compliance cannot be demonstrated by a policy library alone. A regulator, auditor or management body may need to understand not only what an organisation intended to do, but also whether its cybersecurity measures were approved, implemented, tested and improved over time. That distinction makes evidence management a central part of NIS2 readiness. Policies describe the expected approach. Evidence shows that people followed it, controls operated, exceptions were governed and material weaknesses reached the right decision-makers. Directive (EU) 2022/2555, known as NIS2, does not prescribe one universal folder of documents for every regulated entity. It establishes outcomes and minimum areas that essential and important entities must address through appropriate and proportionate technical, operational and organisational measures. The exact records expected from an entity depend on its risk profile, services, sector, size, national implementing law and, in some cases, sector-specific EU rules. This guide explains how businesses can build practical NIS2 compliance documentation, what evidence may support Articles 20, 21 and 23 of the Directive, and how to organise a defensible evidence pack without creating unnecessary bureaucracy. It is designed as a documentation and assurance guide—not as another general implementation roadmap or audit checklist. 1. Does NIS2 require specific compliance documentation? NIS2 does not contain a single exhaustive schedule titled “documents every entity must maintain”. Instead, it creates duties that are difficult to perform or demonstrate without reliable records. Article 20 requires management bodies of essential and important entities to approve cybersecurity risk-management measures, oversee their implementation and follow relevant training. Article 21 requires appropriate and proportionate risk-management measures covering at least ten specified areas. Article 23 establishes staged reporting for significant incidents. Supervision provisions allow competent authorities to request information and access data, documents or other evidence needed for their tasks. As a result, documentation should support three questions: What decision, process or control was required? Who approved, owned or performed it, and when? What evidence shows that it operated and produced the intended result? National legislation may define additional documents, registration information, audit requirements, reporting forms or retention periods. Organisations operating in several Member States should therefore maintain a jurisdiction register instead of assuming that one evidence pack satisfies every national procedure. Certain DNS, cloud, data-centre, managed service, managed security, online marketplace, online search, social networking and trust service providers are also subject to Commission Implementing Regulation (EU) 2024/2690. For those entities, the Regulation and ENISA’s supporting technical guidance provide more detailed requirements and examples. Other entities may use that material as a reference, but should not present it as automatically binding outside its legal scope. 2. Documentation, records and evidence: what is the difference? These terms are often used interchangeably, but separating them improves assurance. Category Purpose Examples Governing documents Define what the organisation expects and who is responsible Policies, standards, procedures, governance charters and control descriptions Operational records Show that a process or control was performed Access reviews, vulnerability tickets, backup logs, supplier assessments and training records Decision evidence Shows how risks, exceptions and priorities were considered Management minutes, risk acceptance, investment approvals and escalation records Effectiveness evidence Shows whether measures work as intended Test results, restoration exercises, metrics, audits and verified remediation Regulatory records Support registration, notification and supervisory engagement Scope analysis, authority correspondence, incident reports and information requests A policy is not proof that the process operates. A screenshot is not necessarily reliable evidence if its source, date, scope and owner are unclear. A test report has limited value if no one owns the findings or verifies their closure. Strong evidence connects design with operation. It should allow a reviewer to trace a requirement to a control, the control to its owner, the owner to operational records and any failure to a documented decision or corrective action. 3. Build a NIS2 evidence map before collecting files Collecting everything creates cost, confusion and additional security risk. A better approach begins with an evidence map. An evidence map links each applicable obligation to the entity’s controls and records. It can be maintained in a governance, risk and compliance platform or a controlled spreadsheet, provided ownership, versioning and access are appropriate. Evidence-map field What to record Legal or control reference Applicable NIS2 article, national provision, implementing rule or internal control requirement Expected outcome The risk or service outcome the measure should achieve Control description How the organisation addresses the outcome Owner and operator Who is accountable and who performs the activity Evidence source System, repository or process producing the record Frequency or trigger Monthly, quarterly, annually, after change or after an incident Reviewer Who assesses completeness and effectiveness Retention and protection How long evidence is kept and how access and integrity are protected Status and exceptions Current result, open gaps, accepted risk and remediation The map should reflect the services and systems in scope. A generic template can accelerate the work, but it should not become the basis for unsupported declarations. Where a control does not apply, the organisation should record the reason rather than leaving an unexplained blank. 4. Scope and applicability records An organisation cannot build credible NIS2 compliance documentation without first establishing which entities and services are covered. Scope evidence is especially important for corporate groups, cross-border operations and businesses whose activities cross several sectors. A documented applicability file may include: a list of relevant legal entities and establishments; services and activities mapped to Annex I or Annex II of NIS2 and corresponding national provisions; employee and financial data used for size classification; analysis of partner and linked enterprises where relevant to SME calculations; size-independent rules and any specific designation decisions; jurisdiction and competent-authority mapping; interaction with sector-specific EU legislation, such as DORA; legal advice or internal interpretation supporting uncertain classifications; review triggers for acquisitions, new services, restructuring and legislative change. The purpose is not to produce a long legal memorandum for every entity. It is to make the conclusion reproducible. A reviewer should be able to see what facts were considered, which version of the law was used and who approved the result. Scope documentation should also identify the network and information systems supporting covered services. Legal entity boundaries do not always match technical boundaries. Shared identity platforms, cloud tenants, data centres or managed providers may support several companies and services, making dependency evidence important. 5. Governance and management-body evidence Article 20 makes management involvement a substantive requirement. Evidence should show more than the presence of cybersecurity on an annual agenda. 5.1 Approval of cybersecurity risk-management measures Approval evidence can include board or management-body minutes, resolutions, decision papers and approved policy sets. The record should identify what was approved, the scope of the decision, material risks, known limitations, required resources and the reporting mechanism used to oversee implementation. Where a large package is approved, a controlled index can identify all included documents and their versions. This avoids uncertainty about whether a policy was actually part of the decision. 5.2 Oversight of implementation Oversight records may include periodic dashboards, risk committee minutes, programme status reports, overdue-action escalations and decisions concerning residual risk. Reporting should enable informed challenge. Useful indicators connect controls with service outcomes. Examples include the proportion of critical services covered by tested recovery plans, overdue remediation for critical vulnerabilities, privileged access awaiting review, critical suppliers without current assurance and high-risk audit findings past their agreed date. Raw activity counts are weaker. The number of alerts processed or employees trained may be relevant, but it does not by itself show whether the organisation can protect and recover its services. 5.3 Management training Training evidence should record the audience, date, subject matter, facilitator and completion. The content should help management understand its responsibilities, the entity’s threat and risk profile, significant-incident escalation, risk acceptance and oversight expectations. An attendance list alone may not demonstrate that training was suitable. Agenda materials, learning objectives, exercises or confirmation of understanding provide stronger context. 5.4 Accountability and delegated responsibility An organisation should maintain a current responsibility model. This can include governance terms of reference, role descriptions, RACI matrices, escalation paths and authority for risk acceptance. Operational tasks may be delegated to security teams, technology owners or providers. Documentation should still show how the management body receives assurance and how material matters are escalated. Outsourcing a control does not outsource the regulated entity’s responsibility for managing its risk. 6. Risk-analysis and treatment evidence Article 21 begins with policies on risk analysis and information-system security. A defensible evidence trail demonstrates that risk management affects decisions and investment. Core documentation may include: the approved cybersecurity risk methodology; risk criteria, impact scales and likelihood definitions; a service, process, information and technology inventory; risk assessments and a current risk register; treatment plans with owners, resources and deadlines; risk acceptance and exception records; reassessment after material change or an incident; links between risks, controls, suppliers and continuity priorities. The risk register should not be an isolated spreadsheet owned only by the security team. Material risks need accountable business owners and a route to management. Treatment records should make clear whether the organisation is reducing, avoiding, transferring or accepting the risk. Exceptions require particular care. A patching exception, unsupported system or delayed access review should identify the affected service, reason, compensating measures, approver, expiry date and review. Open-ended exceptions weaken both security and evidence quality. 7. Evidence for the Article 21 risk-management areas The following examples illustrate records that may support the ten minimum areas in Article 21. They are not a universal statutory checklist. Article 21 area Examples of useful evidence Risk analysis and system-security policies Methodology, risk register, policy approvals, review history and exception records Incident handling Response plan, severity criteria, incident tickets, communication logs, exercise reports and lessons learned Business continuity, backup and crisis management Business impact analysis, recovery objectives, continuity plans, backup monitoring, restoration results and crisis exercises Supply-chain security Supplier inventory, risk tiering, due diligence, security clauses, assurance reports, monitoring and exit plans Secure acquisition, development and maintenance Security requirements, architecture reviews, secure-development records, change approvals, vulnerability tickets and patch evidence Assessment of effectiveness Control testing, penetration tests, audits, metrics, findings and verified remediation Cyber hygiene and training Baseline standards, update and configuration records, role-based training, simulations and follow-up actions Cryptography and encryption Cryptographic policy, approved standards, key and certificate inventories, rotation logs and exception decisions Human resources security, access and assets Screening where lawful, joiner-mover-leaver records, access reviews, privileged-account evidence and asset inventories MFA and secure communications Coverage reports, enrolment and recovery controls, exception records, authentication tests and emergency communication exercises Evidence must remain proportionate. A small important entity and a multinational essential entity may address the same legal area with different operating models and documentation depth. The key question is whether the record is sufficient to demonstrate the control in the context of the entity’s risk. 8. Incident-reporting documentation Article 23 requires essential and important entities to notify significant incidents through a staged process. The Directive provides for an early warning without undue delay and within 24 hours of awareness, an incident notification within 72 hours, and generally a final report within one month of the incident notification. Intermediate or progress reports may also be required. Incident evidence should support both response and the reporting decision. Useful records include: the time and source of initial detection; the point at which the organisation became aware of the incident; technical and business severity assessments; the significant-incident assessment and its approver; affected services, systems, users and other persons; suspected malicious or unlawful activity; indicators of compromise and cross-border implications where available; containment, mitigation and recovery actions; copies of regulatory submissions and acknowledgements; customer, contractual, data-protection and law-enforcement communications; decision logs showing what was known and unknown at each stage; root-cause findings, lessons learned and corrective actions. 8.1 Preserve a reporting timeline The reporting clock can begin before a complete forensic conclusion is available. A reliable timeline is therefore essential. Systems should use synchronised time sources, and the incident lead should record material decisions as they occur. The evidence should distinguish facts, assumptions and pending investigation. Early notifications can be qualified. A clear record of uncertainty is more credible than retrospective notes that imply the organisation knew everything at the start. 8.2 Document non-reporting decisions Not every security event meets the threshold of a significant incident. When an event is assessed as non-reportable, the organisation should retain a proportionate record of the facts, criteria and decision. This helps demonstrate consistency and enables later reassessment if the impact changes. National law, authority guidance and the Commission Implementing Regulation for specified digital and ICT entities may provide additional thresholds and procedural detail. Reporting templates and contact information should be maintained for every relevant jurisdiction. 9. Supply-chain and supplier evidence Supplier documentation should show that the organisation understands which relationships could affect its covered services and applies scrutiny proportionate to the risk. An evidence set may contain: a supplier inventory linked to services and information assets; inherent-risk and criticality classifications; due-diligence questionnaires and supporting documents; independent assurance reports and certifications, with scope and exceptions reviewed; security requirements in contracts and statements of work; incident-notification and cooperation provisions; subcontracting, location and concentration-risk information; access granted to supplier personnel and periodic access reviews; performance, vulnerability and incident monitoring; reassessment records following change or an incident; continuity, substitution and secure-exit plans. A certificate should not be stored without analysis. Its scope, period, exclusions and relationship to the delivered service matter. Similarly, a completed questionnaire is a supplier statement, not independent proof. Higher-risk suppliers may require interviews, technical evidence, independent reports or contractual verification rights. Documentation should also record the organisation’s response to deficiencies. Accepting a supplier risk without an owner, expiry date or compensating measure creates an unmanaged exception. 10. Business continuity, backup and recovery evidence Continuity documentation should connect business priorities with technical recovery capability. The evidence chain may begin with business impact analysis and service dependency maps. These should support recovery time and recovery point objectives, response priorities, backup architecture, alternative procedures and supplier arrangements. Operational evidence can include: current continuity, disaster-recovery and crisis-management plans; protected backup configuration and monitoring; restoration tests showing which data and systems were recovered; actual recovery duration compared with approved objectives; test limitations, failures and remediation; exercise attendance, decisions and lessons learned; emergency contacts and out-of-hours escalation checks; evidence that critical providers participated where relevant. A successful backup job is not the same as a successful recovery. Evidence should demonstrate that required data can be restored into an operable service under plausible conditions. Testing should vary scenarios. Tabletop exercises are useful for decisions and communication, while technical restoration tests provide evidence of recovery capability. More complex entities may use integrated exercises involving suppliers, facilities and business teams. 11. Security-control and technical evidence Technical evidence is often abundant but difficult to interpret. The objective is not to export every log. It is to retain records that demonstrate scope, operation, review and response. Examples include: approved secure-configuration baselines and compliance reports; vulnerability scan coverage and remediation tickets; patch status linked to criticality and exceptions; endpoint, network and cloud monitoring coverage; identity and privileged-access reviews; MFA coverage and bypass exceptions; encryption, key and certificate management records; change approvals and security testing; secure-development and dependency-scanning results; asset inventory completeness checks; alert investigations and response outcomes. Tool screenshots should be used carefully. Prefer repeatable reports or system exports with the source, timestamp, query scope and responsible reviewer recorded. Evidence should be protected from unauthorised modification, particularly when it may support an investigation. 12. Evidence that measures are effective Article 21 includes policies and procedures to assess the effectiveness of cybersecurity risk-management measures. This means documentation should go beyond implementation status. An effectiveness file can combine: defined control objectives and success criteria; control self-assessments; technical testing and independent review; security and resilience metrics; internal and external audit reports; incidents and near misses indicating control performance; trends and recurring weaknesses; corrective actions with owners and deadlines; proof that high-risk remediation was independently verified. Metrics should be interpreted. For example, “98% of critical systems patched on time” requires a defined population, a reliable inventory, treatment of exceptions and information about the remaining 2%. A positive average can conceal exposure in a critical service. Management reporting should distinguish control design, implementation and effectiveness. A control can be well designed but inconsistently operated, or widely deployed but ineffective against a realistic threat. 13. How to assemble a NIS2 evidence pack An evidence pack is a controlled view of relevant records, not a permanent duplicate of every operational file. 1. Start with an index The index should identify the requirement, document or evidence item, owner, version or period, source location, access classification and review status. It should also identify unavailable evidence and open remediation. 2. Use service-based navigation Regulatory obligations apply to entities, but operational impact occurs through services. Organising evidence around covered services helps reviewers understand dependencies, risks, controls and recovery priorities. 3. Select representative periods and samples Evidence should show operation over time. One access review performed immediately before an assessment does not demonstrate a mature quarterly process. Samples should cover the relevant period, locations and technologies. 4. Preserve source and context Each item should make clear where it came from, who produced or approved it, the date, scope and meaning. Remove unexplained screenshots, unlabeled exports and drafts that could be mistaken for approved records. 5. Record gaps honestly Do not create evidence retrospectively to imply that an activity occurred. Where evidence is missing, document the gap, immediate risk response, owner and remediation date. Transparent remediation is more defensible than an unreliable record. 6. Perform quality review Legal, security, risk and service owners should check consistency. The asset inventory should agree with vulnerability coverage. Supplier classification should drive assurance. Recovery objectives should match test reports. Management minutes should reflect the material risks shown in dashboards. 14. Evidence quality principles A practical evidence standard can be expressed through seven characteristics: relevant: it supports a defined requirement or control; authentic: its origin and ownership can be established; complete: it includes the scope and context needed for interpretation; accurate: it reflects what actually occurred; timely: it covers the required period and was produced at the appropriate time; protected: access, integrity and confidentiality are controlled; retrievable: authorised teams can find it when required. These principles help teams decide whether a proposed record adds assurance or merely volume. 15. Retention, confidentiality and evidence security NIS2 does not establish one universal retention period for every type of compliance record. Retention should be determined using national requirements, limitation periods, sector rules, contractual duties, audit cycles, incident-investigation needs and the organisation’s risk. Evidence may contain sensitive architectural details, vulnerabilities, personal data, credentials, supplier information or legal advice. It should be classified and protected accordingly. Collecting material for an assessment does not justify placing unrestricted copies in a shared folder. The organisation should define: approved repositories and access roles; version control and approval status; retention and defensible disposal; legal hold and investigation procedures; integrity protection and backup; secure transfer to auditors or authorities; handling of personal and privileged information; return or deletion of assessment copies. Data minimisation matters. Evidence should be sufficient for its purpose without exposing unnecessary personal data, secrets or complete security configurations. 16. Common NIS2 documentation mistakes 16.1 Treating policies as proof of operation Policies establish intent. They need corresponding reviews, logs, tests, decisions and corrective actions. 16.2 Collecting screenshots without context A screenshot may not show the source, date, population, filters or reviewer. Use controlled exports and explanatory notes where possible. 16.3 Building the evidence pack only before an audit Last-minute collection produces gaps and inconsistent records. Evidence generation should be embedded into normal control operation. 16.4 Keeping expired exceptions open Exceptions should have owners, compensating measures and expiry dates. Repeated extensions require appropriate challenge and escalation. 16.5 Storing sensitive evidence too broadly Centralisation improves retrieval but can create a valuable target. Use classification, least privilege, logging and secure transfer. 16.7 Ignoring contradictory records An approved policy may claim quarterly reviews while operational records show annual activity. Resolve discrepancies instead of presenting them as separate truths. 16.8 Equating certification with complete NIS2 evidence ISO/IEC 27001 certification can provide useful governance and control records. It does not automatically demonstrate legal scope, national notification procedures or every NIS2 outcome. The certification scope and statement of applicability must be understood. 17. NIS2 compliance documentation checklist Use this checklist as a planning aid. Adapt it to the entity, national law and risk profile. [ ] Applicability and jurisdiction analysis is documented and approved. [ ] Covered services, systems, data, people, facilities and suppliers are mapped. [ ] Management approval of risk-management measures is traceable. [ ] Management oversight and cybersecurity training records are current. [ ] Roles, escalation paths and risk-acceptance authority are defined. [ ] Risk methodology, assessments, register and treatment plans are maintained. [ ] Policies are version-controlled, approved and linked to operating procedures. [ ] Incident records preserve awareness, decisions, actions and reporting timelines. [ ] Non-reporting decisions for material events use documented criteria. [ ] Continuity and recovery documentation is linked to critical services. [ ] Backup and restoration evidence demonstrates recoverability. [ ] Supplier inventory, classification, due diligence and monitoring are current. [ ] Security clauses and supplier-exit arrangements reflect criticality. [ ] Vulnerability, patch, configuration and change records show control operation. [ ] Access, privileged accounts and MFA exceptions are reviewed. [ ] Cryptographic keys and certificates are governed and monitored. [ ] Training evidence is role-based and includes effectiveness indicators. [ ] Control testing and audits produce owned, time-bound remediation. [ ] High-risk findings have verified evidence of closure. [ ] Evidence retention, access, integrity and secure transfer are defined. [ ] The evidence index identifies missing or outdated records. [ ] Evidence is reviewed after major incidents, changes and regulatory updates. 18. How this guide fits with implementation and audit work Documentation should emerge from real controls. Organisations that are still designing their programme can use TTMS’s practical guide to implementing NIS2 for a broader implementation perspective. For a general overview of business duties, see cybersecurity obligations of businesses under NIS2. An implementation programme creates and operates controls. An evidence programme makes their ownership, decisions and results demonstrable. An audit or assessment then evaluates whether the measures and evidence satisfy the applicable criteria. These activities support one another but should not be confused. 19. Why TTMS? Building a NIS2 evidence model requires an understanding of regulation, governance and the technology that generates operational records. TTMS can support organisations in mapping applicable requirements to services, controls, owners and evidence sources, then integrating those records into practical workflows. Support may include evidence-readiness assessments, governance and responsibility design, control mapping, documentation frameworks, supplier assurance, incident and continuity exercises, technical-control verification and remediation planning. The objective is not to create documents for their own sake. It is to help the organisation establish records that reflect working security measures and provide management with reliable assurance. Engagement scope should be tailored to the entity’s legal position, national requirements, risk profile and existing management systems. Legal conclusions should be confirmed by appropriately qualified advisers, while technical and organisational evidence should support those conclusions accurately. 20. Prepare a defensible NIS2 evidence pack Organisations should not wait for an authority request or audit notice before locating their records. Start with the services in scope, the decisions management must make and the controls protecting those services. Then identify which reliable records demonstrate operation and effectiveness. Contact TTMS to discuss a NIS2 documentation and evidence-readiness assessment tailored to your organisation. For authoritative background, consult the European Commission overview of the NIS2 Directive, ENISA’s NIS2 implementation resources and the official text of Directive (EU) 2022/2555 on EUR-Lex. 21. Frequently asked questions about NIS2 compliance documentation What documentation is required for NIS2 compliance? NIS2 does not prescribe one universal document pack. Covered entities need records sufficient to demonstrate management approval and oversight, appropriate and proportionate risk-management measures, significant-incident reporting and compliance with applicable national procedures. Typical evidence includes scope analysis, governance decisions, risk records, policies, operational control records, supplier assurance, continuity tests, incident files, metrics, audits and remediation. Is a policy enough to prove NIS2 compliance? No. A policy describes the intended approach. Evidence of operation may include approvals, system records, reviews, test results, incidents, exceptions and corrective actions. A reviewer should be able to connect the policy to actual controls and accountable owners. Does NIS2 require an information security management system? NIS2 requires a governed set of appropriate and proportionate cybersecurity risk-management measures. National law may expressly require an information security management system, and an ISMS is a practical way to organise policies, risk management, controls and improvement. Organisations should verify the terminology and detailed requirement in each relevant jurisdiction. Does ISO 27001 certification provide sufficient evidence? ISO/IEC 27001 certification can provide valuable evidence, but it is not automatic proof of complete NIS2 compliance. The certification scope, exclusions and statement of applicability matter. Legal scope, management duties, national registration and incident-reporting procedures still require specific assessment. How long should NIS2 evidence be retained? There is no single NIS2 retention period covering every record. The organisation should define retention using national law, sector obligations, audit cycles, limitation periods, contractual duties, investigation needs and risk. Sensitive evidence should be disposed of securely when retention is no longer justified. Should every security log be placed in the evidence pack? No. The pack should provide a controlled view of relevant evidence. Operational logs may remain in their source systems, with an index describing ownership, scope, retention and retrieval. Export only what is necessary and protect sensitive technical information. What evidence should the management body receive? Management should receive information enabling approval and effective oversight: material risks, measure implementation, significant incidents, control failures, critical supplier exposure, effectiveness results, overdue high-risk actions and decisions requiring acceptance or investment. How should incident-reporting decisions be documented? Record awareness time, affected services, severity and impact, applicable thresholds, known and unknown facts, the decision-maker and the basis for reporting or not reporting. Keep copies of notifications, acknowledgements and subsequent updates. Follow applicable national procedures. What supplier evidence is useful for NIS2? Useful records include supplier criticality, due diligence, assurance reports, contractual security provisions, access reviews, monitoring, incident cooperation, continuity arrangements and exit plans. Evidence depth should reflect the supplier’s access and potential impact on covered services. How often should the NIS2 evidence pack be reviewed? Set a risk-based schedule and update records through normal operations. Additional review should follow material incidents, acquisitions, major system or service changes, new critical suppliers, significant control failures and legal updates. Who should own NIS2 compliance documentation? Ownership is distributed. Legal or compliance teams may maintain the requirements map, while security, IT, service owners, procurement, HR and continuity teams own operational records. A central coordinator should manage the evidence index, quality checks and escalation without becoming the artificial owner of every control.
Read
5 Most Common Gaps Identified When Preparing for KSC 2.0
Preparing an organization for KSC 2.0 involves more than drafting security policies and incident response procedures. Only an assessment of how the organization actually operates can show whether documented rules are followed in practice, responsibilities have been clearly assigned and teams can respond effectively under time pressure. It is particularly important now that the Polish amendment to the Act on the National Cybersecurity System, implementing the NIS2 Directive, is already in force. The provisions took effect on 3 April 2026. Entities that met the criteria for classification as a key or important entity on that date and are not entered ex officio in the KSC Register should submit an application for entry by 3 October 2026. Organizations are therefore no longer preparing for a future regulation; they are implementing specific obligations concerning, among other things, risk management, incident handling, business continuity and supplier security. Based on gap analyses and compliance audits conducted by TTMS experts in 2026, we have observed that the issue is rarely a single isolated non-compliance. More often, organizations face several interconnected deficiencies that can make it harder to meet statutory requirements and delay incident response. This article presents the five gaps we identify most frequently, their practical consequences and the areas that should be verified first. 1. What Is a NIS2 Audit and Why Does Your Organization Need One? A NIS2 audit is an assessment process used to determine how effectively an organization meets the requirements of the Directive and the Polish Act on the National Cybersecurity System. In practice, TTMS auditors review IT systems, risk management procedures and incident response plans, and then compare the actual state of operations with the applicable legal obligations. The assessment of security measures is based primarily on Article 21 of the NIS2 Directive and Article 8 of the KSC Act, which requires the implementation of an information security management system. Organizations that verify compliance early gain time to implement improvements in a controlled manner instead of acting under the pressure of an inspection. 1.1 The NIS2 Directive in Brief The NIS2 Directive is an EU legislative act on the security of network and information systems that replaced the earlier NIS framework. It introduces significantly stricter requirements than its predecessor, particularly for organizations whose operations are important to the functioning of the state and the economy. Its purpose is to harmonize security standards across the European Union and materially strengthen resilience against cyberattacks. 1.2 Purpose and Scope of a NIS2 Compliance Audit The purpose of an audit is to assess the extent to which an organization meets the Directive’s requirements and to identify specific security gaps together with a remediation plan. The scope covers both technical matters, such as network configuration and access management, and organizational matters, including security policies, risk management procedures and business continuity plans. A well-executed audit produces an actionable implementation roadmap, not merely a list of deficiencies. 2. Who Is Subject to KSC 2.0 and When Is an Audit Required? The amendment covers key and important entities operating in the sectors listed in Annexes 1 and 2 to the Act, including energy, transport, healthcare, digital infrastructure, selected manufacturing industries and digital services. Whether an organization falls within the scope of the Act depends on its sector, type of activity, company size and specific statutory criteria. Some entities are covered regardless of their headcount or turnover. 2.1 Covered Sectors and Company Size The threshold of 50 employees or EUR 10 million in turnover should not be treated as a standalone test. In many sectors, medium-sized or large-enterprise status is the starting point, but the Act provides exceptions and separate qualification rules. The first step should therefore be to compare the organization’s actual activities with Article 5 and Annexes 1 and 2 to the KSC Act. 2.2 Key Entities and Important Entities: Differences in Requirements Key and important entities are generally subject to a similar set of obligations relating to risk management, incident handling and supply-chain security, subject to the exceptions provided for in the Act and sector-specific regulations. The primary differences concern the supervision and audit model. Under Article 15 of the KSC Act, a key entity must conduct a security audit at its own expense at least once every three years. The competent authority may order an external audit of a key entity at any time and of an important entity following a significant incident or another breach of the Act. 3. Is a NIS2 Audit Mandatory and When Should It Be Performed? Not every gap analysis offered on the market constitutes a statutory audit. The periodic audit obligation under Article 15 applies to key entities, while a voluntary gap analysis can help both key and important entities assess readiness, set priorities and gather evidence of compliance. A statutory audit must be conducted by an organization or by at least two auditors meeting the qualification requirements set out in Article 15(2), while complying with the independence requirement in Article 15(2a). 3.1 Key KSC 2.0 Deadlines in Poland Poland implemented the NIS2 Directive through the Act of 23 January 2026 amending the Act on the National Cybersecurity System and certain other acts (Journal of Laws of 2026, item 252). The Act was published on 2 March 2026, and its principal provisions entered into force on 3 April 2026. For entities that met the criteria for classification as a key or important entity on the effective date, self-registration in the KSC Register runs from 7 May to 3 October 2026, unless the entity is entered ex officio. Entities in this group should comply with the obligations in Chapter 3 no later than 3 April 2027. Key entities in this group must conduct their first statutory security audit by 3 April 2028. For entities brought within the scope of the Act at a later date or entered by administrative decision, the applicable deadline must be determined under the provision governing the relevant procedure. 3.2 How Often Should a Compliance Audit Be Repeated? Under Article 15 of the KSC Act, the statutory audit of a key entity must be conducted at least once every three years. Irrespective of that requirement, we recommend an annual internal compliance review and an additional assessment after any material change, such as an IT infrastructure upgrade, implementation of a new system, a significant incident or a change of a critical service provider. Security cannot be configured once and then forgotten. 4. Consequences of NIS2 Non-Compliance Failure to perform the obligations arising from the KSC Act implementing NIS2 may have serious consequences. These include supervisory measures, orders to remedy infringements and administrative fines. 4.1 Financial Penalties and Administrative Sanctions Entities that fail to perform their obligations under the KSC Act may be subject to supervisory measures and administrative sanctions. The Act provides for high maximum penalties and, where an infringement creates a particularly serious threat, a fine of up to PLN 100 million. Under Article 35 of the amending Act, the new penalties specified in that provision may first be imposed two years after the Act entered into force, generally from 3 April 2028. This does not postpone the deadlines for registration, implementation of obligations or incident reporting. 4.2 Management Liability and Reputational Risk Failure to perform statutory obligations may also result in a personal fine being imposed on the head of a key or important entity. Article 73a of the KSC Act provides for a fine of up to 300% of the person’s remuneration and, for certain public-sector entities, up to 100% of remuneration. The person regarded as the head of a particular entity depends on its legal form and governance structure. Irrespective of sanctions, an incident and disclosed negligence may also undermine the trust of customers and business partners. 5. What Does a NIS2 Audit Cover? This part of our work as auditors is particularly revealing because it shows precisely where organizations encounter the most common difficulties. Below, we describe the five areas in which we most frequently identify gaps during KSC 2.0 readiness projects, together with practical examples and the consequences of leaving them unresolved. 5.1 Unclear Accountability and Immature Risk Management The first thing we verify is who formally holds responsibility for cybersecurity within the organization. Our experience shows that unclear accountability is one of the most frequently identified issues. Roles across IT, security and management may be documented, yet in practice there is no unambiguous decision-making path for every type of significant incident. Valuable hours are then spent determining who is authorized to make a decision instead of responding to the incident. This issue is closely linked to immature risk management. Many organizations have a document entitled ‘Risk Management Policy’, but the assessment was performed only once and has not been updated since. Article 21 of the NIS2 Directive and Article 8 of the KSC Act require appropriate and proportionate technical, operational and organizational measures based on systematic risk management. If an organization cannot demonstrate a recurring process, it also lacks a reliable understanding of where it is genuinely most exposed. 5.2 Incomplete IT and OT Asset Inventory An incomplete or outdated inventory of IT and OT assets appears very frequently in our assessments. A typical example is a manufacturing company that declares full control over its infrastructure, yet during workshops no one can clearly state how many active servers it operates, which systems are outdated or which OT devices can access the corporate network. Without a reliable inventory, risk assessment becomes largely theoretical: an organization cannot assess the risk associated with an asset it does not know exists. During an incident, the team then loses time determining what has actually been compromised. 5.3 Untested Incident Response Procedures Our observations indicate that, in most organizations assessed, the incident response procedure existed only as documentation and had never been tested in practice. Article 23 of the NIS2 Directive and Article 11 of the KSC Act provide for multi-stage reporting: an early warning must be submitted without undue delay and no later than 24 hours after detecting a significant incident, followed by an incident notification no later than 72 hours after detection. The required reports must then be submitted, including a final report generally within one month of the incident notification. The procedure must therefore work at night, at weekends and when key personnel are unavailable. 5.4 Inadequate Business Continuity Plans An incident response procedure is not sufficient if the organization cannot maintain or restore critical services. In practice, we verify whether business continuity and disaster recovery plans cover critical dependencies, suppliers, backups, crisis communications and realistic recovery times. Article 21(2) of the NIS2 Directive and Article 8 of the KSC Act identify business continuity, backup management, disaster recovery and crisis management as elements of cybersecurity risk-management measures. A plan that has never been tested remains an assumption rather than evidence of resilience. 5.5 No Systematic Supplier Risk Assessment Supplier security management remains one of the greatest challenges. In the vast majority of organizations assessed by TTMS, there was no systematic evaluation of risks associated with service providers or partners that had access to the organization’s systems. Article 21(2)(d) of the NIS2 Directive and Article 8 of the KSC Act expressly cover supply-chain security. A typical example from our work is an external IT provider with remote access to company systems whose security controls have never been verified. An attack on such a partner can directly threaten the organization using its services. 5.6 Summary of the Five Most Common Gaps Area Observation from TTMS Projects 1. Accountability and risk management Frequently identified issue 2. IT and OT asset inventory Very frequent 3. Testing of incident response procedures Most organizations assessed 4. Business continuity Often requires additional testing and clarification 5. Supplier risk assessment The vast majority of organizations assessed High-risk gaps identified in a single audit Usually between one and several The data in the table consists of anonymized qualitative observations from gap analyses and audits conducted by TTMS in 2025–2026. It is not a representative market study. 7. How a NIS2 Audit Works: Step by Step Below, we explain how we conduct a NIS2 audit for a client, step by step, from the initial contact through to the completed remediation roadmap. Step 1: Determine Whether the Organization Is Subject to KSC 2.0 The first step is to establish whether the organization is subject to the KSC Act and whether it qualifies as a key or important entity. This determination defines the subsequent scope of the assessment and the obligations that must be considered. Step 2: Questionnaire and Baseline Data Collection We then conduct a detailed questionnaire and collect baseline information from the IT, security and management teams. This allows us to build an initial picture of the organization’s security posture before examining the documentation in detail. Step 3: Review of Documentation and Processes The next stage involves reviewing the documentation and existing processes, comparing what is written on paper with what actually happens within the organization. This is where the discrepancies described earlier most often become visible, such as an incident response procedure that exists but has never been tested. Step 4: Workshops and Team Interviews We conduct workshops and interviews with employees from different departments because documentation rarely tells the whole story. A conversation with a network administrator or the person responsible for supplier relationships often reveals more than a formal review of documents. Step 5: Findings and Recommendations Report At the end of the assessment, we prepare a detailed report presenting the findings and specific remediation recommendations in language that is understandable not only to IT, but also to the organization’s management. The head of the entity and the relevant governing bodies are responsible for approving and overseeing implementation of the measures to the extent required by the Act and the entity’s governance structure. Step 6: Remediation Roadmap The final report includes a prioritized remediation roadmap. In practice, we typically identify between one and several high-risk non-compliances during a single audit. The roadmap is therefore not about implementing every recommendation at the same time, but about sequencing activities to reduce the most significant business risks as quickly as possible. 8. How to Prepare Your Organization for a NIS2 Audit Preparing for a NIS2 audit requires involvement from every department, not only IT. It is worth collecting current security policy documentation, a list of systems and external suppliers, and appointing a person to act as the auditors’ primary point of contact. The better prepared the organization is at the outset, the faster and more efficiently the process can be completed, reducing both cost and pressure on the team. 9. NIS2 Audits and Other Security Audits: Key Differences A NIS2 and KSC 2.0 compliance assessment differs from other security reviews because it addresses specific regulatory obligations arising from the Act on the National Cybersecurity System. ISO/IEC 27001 certification is generally voluntary, while a GDPR compliance audit focuses on personal data protection obligations. These scopes may partially overlap, but none of them automatically replaces an assessment of compliance with KSC 2.0. 10. Benefits of Commissioning a NIS2 Audit from TTMS TTMS is a global IT company specializing in the implementation and maintenance of bespoke IT systems, business process automation and outsourcing services. With experience in systems integration, Salesforce, Microsoft and AEM implementations, as well as IT service management, our consultants understand not only regulatory requirements but also the real-world IT infrastructure architectures our clients operate. 10.1 Scope and Delivery of Our Service We provide a comprehensive NIS2 and KSC 2.0 readiness and gap assessment covering all the areas described above: from asset inventory, risk management and incident response procedures to supply-chain security. We follow a proven process, starting with an initial questionnaire, continuing through team workshops and concluding with an actionable roadmap. If the engagement includes a statutory audit under Article 15, the scope, auditor qualifications and independence requirements must be confirmed separately. 10.2 Support with Implementing Post-Audit Requirements The real value of an audit lies in implementing its recommendations, not merely producing a report. After completing projects, we observe that clarifying accountability, updating documentation and implementing remediation measures shorten incident response times, improve asset records and reduce the number of non-compliances found during subsequent reviews. Our support includes security process automation, integration of monitoring systems and development of procedures that work in teams’ day-to-day operations. 11. Contact a TTMS Expert and Prepare Your Organization for a NIS2 Audit 11.1 Make Sure Your Organization Is Ready for KSC 2.0 KSC 2.0 readiness is difficult to assess from documentation alone. The key is to verify whether responsibilities, processes and safeguards work in practice and whether the organization can demonstrate compliance during an audit or inspection. If you would like to discuss your organization’s situation, contact TTMS experts. We will help determine which areas require verification, what audit scope is appropriate and where preparations should begin. We will tailor the engagement to the entity’s status and its obligations under KSC 2.0. 12. Legal Basis and Sources Directive (EU) 2022/2555 of the European Parliament and of the Council (NIS2), in particular Articles 20, 21, 23, 32 and 33; the Act of 5 July 2018 on the National Cybersecurity System, as amended by the Act of 23 January 2026 (Journal of Laws of 2026, item 252), in particular Articles 5, 8, 11, 15, 73 and 73a and Annexes 1 and 2; Articles 33–35 of the amending Act; and communications from the Polish Ministry of Digital Affairs concerning the KSC Register and the S46 System. The legal status and implementation timeline were verified on 13 July 2026. 13. FAQ Is a Gap Analysis the Same as a Statutory KSC Audit? No. A gap analysis is a voluntary readiness assessment that helps identify deficiencies and prioritize actions. A statutory security audit under Article 15 of the KSC Act must meet the requirements relating to scope, auditor qualifications and independence. What Is a NIS2 Compliance Audit? A NIS2 compliance audit is a market term for an assessment process that verifies an organization’s readiness for the requirements of the NIS2 Directive and the KSC Act. It may cover IT systems, risk management and incident response. However, not every such review constitutes a statutory security audit under Article 15 of the KSC Act, which must meet the applicable requirements concerning scope, auditor qualifications and independence. What Does NIS2 Involve? NIS2 is an EU directive that introduces rigorous network and information systems security requirements for organizations in key and important sectors. Its purpose is to harmonize security standards across the European Union and strengthen resilience against cyberattacks. How Much Does a NIS2 Audit Cost? The cost of a NIS2 audit depends on the size of the organization, the number of systems and locations covered by the review, and the scope of support required to implement the recommendations. An accurate quotation can be provided after a short initial discussion in which we establish the actual scope of work.
Read