Home •Blog
TTMS Blog
TTMS experts about the IT world, the latest technologies and the solutions we implement.
Sort by topics
LXP vs LMS: Which Platform Wins in 2026?
LMS and LXP platforms solve different learning challenges. An LMS is designed to manage, deliver, and track structured training, while an LXP focuses on personalized, learner-driven learning and continuous skill development. Many organizations don’t choose one over the other. Instead, they use both to support different learning objectives. Choosing between them can feel a bit like deciding between a library and a streaming service. One organizes learning in a structured way, while the other helps people discover relevant content based on their interests, goals, and previous activity. It’s a simple comparison, but it captures why the LMS vs LXP discussion continues to shape corporate learning strategies. From our experience working with enterprise learning programs, one of the most common misconceptions is that an LXP is simply a newer version of an LMS. In reality, the two platforms serve different purposes. Organizations that see the best learning outcomes typically treat them as complementary technologies, using each where it delivers the greatest value. Understanding those differences is essential before investing in a learning platform. The right choice depends not only on the features you need today but also on how your organization plans to develop skills, manage compliance training, and support continuous learning over time. 1. LXP vs LMS: Understanding the Core Difference Before You Choose Who actually drives the learning experience? With an LMS, the organization does. Administrators design structured courses, assign them to learners, and track completion. With an LXP, the learner takes ownership. The platform surfaces relevant content, suggests next steps, and encourages exploration. Think of an LMS as a formal curriculum and an LXP as a personalized learning feed. Neither is inherently superior. What matters is whether the platform fits your learning strategy, your workforce profile, and the outcomes you’re actually trying to drive. That distinction also shapes how your L&D team operates, how your IT infrastructure connects, and how your employees feel about learning at work. 2. What Is an LMS? Purpose, Features, and Best-Fit Use Cases A Learning Management System is the backbone of corporate training in most organizations. It centralizes, delivers, and tracks formal learning, particularly in environments where consistency and compliance aren’t optional. Onboarding new hires and certifying staff in regulated industries are two of its most common applications, and in both cases the LMS provides the structure that keeps programs running reliably at scale. 2.1 How an LMS Structures and Delivers Learning An LMS organizes content into predefined courses and learning paths. Learners receive assignments, complete modules in sequence, pass assessments, and receive certificates or completion records. Everyone in a given role or department ends up meeting the same standard. This works well when the goal is measurable competency. A new safety technician needs to complete specific modules before working on-site. A financial advisor must pass compliance training before advising clients. The LMS produces a clear, documented trail of who learned what and when, which is often a legal requirement rather than just an internal preference. 2.2 Core LMS Features That Drive Compliance and Administration A strong LMS is built around control, structure, and governance. It helps administrators track completion rates, assessment results, certification status, and mandatory training progress without digging through separate files or manual reports. It also supports role-based enrolment, automated reminders, and audit-ready documentation, which is why LMS platforms remain essential in regulated sectors such as healthcare, finance, manufacturing, and aviation. The problem starts when organizations expect an LMS to create the whole learning experience. Most LMS platforms are not designed to spark curiosity, recommend content based on individual goals, or make learning feel self-directed. They are excellent at answering the question: “Has this person completed the required training?” They are usually weaker at answering: “What should this person learn next to grow in their role?” That is the gap an LXP is designed to fill. 3. What Is an LXP? Purpose, Features, and Best-Fit Use Cases A Learning Experience Platform puts learners at the center. Rather than assigning fixed courses, an LXP pulls content from multiple sources, curates it based on individual preferences and goals, and surfaces what’s most relevant to each person. It ends up feeling more like a professional development hub than a training portal. 3.1 How an LXP Personalizes and Surfaces Learning Personalization in an LXP relies on AI and machine learning to analyze how each learner interacts with the platform: what topics they engage with, what skills they’ve listed, what their peers in similar roles explore. A software engineer who watches content on cloud architecture will see more relevant resources appear in their feed. A marketing manager who finishes a course on data analytics might get suggestions on audience segmentation or attribution modeling. That kind of timely relevance is what keeps learning from feeling static. The results are measurable. 88% of LXP users agree that an LXP provides a better learning experience than a traditional LMS, and 58% of HR leaders report improved training ROI through AI-curated learning journeys, which is the core capability LXPs are built around. 3.2 Core LXP Features That Drive Engagement and Discovery An LXP is strongest when learning is not limited to assigned courses. It helps employees discover relevant content, follow their interests, and learn from people inside the organization. Instead of relying only on a fixed training catalogue, an LXP can bring together content from internal knowledge bases, external providers, videos, podcasts, articles, and expert recommendations. Social learning features add another layer: employees can recommend resources, comment on materials, share achievements, and learn from colleagues who face similar challenges. This is where an LXP becomes more than a content library. With user-generated content, internal subject matter experts can contribute practical knowledge from real projects, customer cases, tools, or processes. From our experience, this often makes the platform more valuable than a polished but generic course catalogue because employees trust knowledge that comes from people who understand their daily work. The limitation is compliance. If every employee must complete a specific data privacy course by a regulatory deadline, an LXP alone is usually not enough. It may help people discover useful learning, but it does not give administrators the same level of tracking, audit readiness, or enforcement as an LMS. An LXP also needs the right learning culture. If employees see training only as a mandatory task, recommendation engines and social learning features will not create engagement by themselves. In that case, an LXP works best when supported by clear learning paths, manager involvement, and LMS-style structure. 4. LXP vs LMS: Side-by-Side Comparison When comparing LMS and LXP platforms directly, four dimensions reveal the most meaningful differences. In an LMS, administrators own the content entirely. They create, approve, and manage every piece of material learners encounter. An LXP opens that up to multiple contributors, including learners and internal experts, but doing that well requires a governance strategy to keep quality from slipping. Control also works differently in each system. Administrators in an LMS define learning paths, set deadlines, and decide what’s available to whom. In an LXP, learners build their own playlists and search topics that interest them, finding their own way through available content. On reporting, LMS platforms generate detailed audit logs and the documentation compliance officers need during inspections. LXP analytics focus on engagement, content popularity, and skill progression. That data is genuinely useful for L&D strategy, but it doesn’t replace compliance-grade reporting. Integration priorities differ too. An LMS typically connects with HRIS systems, SSO providers, and payroll platforms. An LXP tends to offer broader connectivity with external content libraries, collaboration tools, and skills databases, increasingly linking learning activity to performance management and career development. 5. How to Choose Between an LXP and LMS for Your Organization There’s no universal answer. The right choice depends on your workforce, your industry, your culture, and what you’re ultimately trying to achieve. In our experience helping organizations across healthcare, financial services, and technology evaluate platforms, the compliance question almost always comes first. Everything else tends to follow from there. An LMS is the right fit when compliance, standardization, and accountability are the primary goals. Healthcare providers certifying staff on patient safety protocols, financial institutions managing mandatory regulatory training, and any organization where incomplete training carries legal or operational consequences should build their learning infrastructure around a well-built LMS. An LXP suits organizations that want to build a learning culture rather than simply manage a training program. Companies in technology, creative industries, and professional services often find their workforce learns best through discovery, peer recommendation, and self-directed exploration. An LXP also works well for organizations trying to retain high performers by investing visibly in their career development. 5.1 When You Need Both: The Hybrid Approach 70% of new enterprise learning contracts now specify an LXP component, which reflects how commonly organizations are choosing to run both platforms rather than picking one. The two serve genuinely different purposes, and combining them creates a more complete learning setup than either alone. In a hybrid model, the LMS handles mandatory and compliance-driven training with the rigor and documentation that requires. The LXP sits alongside it, giving employees space to explore voluntary learning, develop skills beyond their current role, and engage with content from diverse sources. A practical example: a 1,500-person financial services organization arrived at a hybrid approach after realizing their compliance certification was well-managed in an LMS, but their technology and operations teams had no structured path for continuous upskilling. By integrating an LXP alongside the existing LMS and connecting both to a shared skills framework, they could enforce regulatory deadlines through the LMS while giving employees a self-directed track for career development. The L&D team gained a unified view of both mandatory completions and voluntary engagement, which made it possible to have more informed conversations about skill gaps at the team level. This integrated approach works particularly well in mid-to-large organizations carrying both compliance responsibilities and genuine ambitions around building a stronger learning culture. 6. How AI Is Reshaping LXP and LMS Platforms in 2026 AI is no longer a future feature in learning platforms. It’s already changing how both LMS and LXP systems work. In LXP systems, AI drives the core personalization engine, making content recommendations sharper and more contextually relevant as the system learns more about each user. In LMS platforms, AI is changing the administrative side: automated tagging reduces manual cataloging work, adaptive assessments adjust difficulty based on performance, and predictive analytics can flag learners at risk of missing compliance deadlines before those problems escalate. At TTMS, we help organizations work through this shift in practice. That means evaluating existing learning infrastructure, identifying where AI adds genuine value, and integrating both platforms into a broader IT setup. The most common mistake we see is organizations deploying an LXP without a minimum content governance framework in place first. Without that structure, user-generated content can erode platform trust quickly, and the self-directed learning culture the LXP was meant to build never really takes hold. 7. The Verdict: Which Platform Wins in 2026? Neither platform is the clear winner, and that is the most practical answer. An LMS is still the stronger choice for structured, compliance-driven training, especially in regulated industries where tracking, reporting, and certification management are non-negotiable. An LXP solves a different problem. It supports discovery, personalization, and continuous skill development in ways a traditional LMS was not designed to deliver. The important shift heading into 2026 is that the line between LMS and LXP platforms is becoming less rigid. AI is making LMS systems more adaptive, while LXP platforms are adding more structure around learning paths, reporting, and compliance support. Vendors are also building tighter integrations and, in some cases, offering combined environments that bring both approaches together. For most organizations, the right decision starts with clarity. Define the learning outcomes you need to achieve, understand what keeps your employees engaged, and assess your compliance requirements honestly. Then choose the platform, or combination of platforms, that matches those realities. The best learning platform is not the newest one. It is the one that fits the work your organization actually needs learning to support. If your organization needs… Choose Why? Mandatory training and regulatory compliance LMS Provides structured training management, certification tracking, reporting, and audit-ready documentation. Employee onboarding LMS Delivers standardized learning paths and ensures every new employee completes the required training. Continuous employee upskilling LXP Recommends personalized learning content based on individual skills, interests, and career goals. Building a learning culture LXP Encourages self-directed learning, knowledge sharing, and ongoing professional development. Compliance training in regulated industries LMS Offers robust reporting, certification management, and compliance monitoring. Career development and skills growth LXP Helps employees develop new capabilities through personalized recommendations and learning journeys. Leveraging internal expert knowledge LXP Makes it easy for subject matter experts to create and share valuable organizational knowledge. Managing both compliance and continuous learning LMS + LXP Combining both platforms provides structured compliance management while supporting personalized employee development. FAQ What is the difference between an LMS and an LXP? An LMS (Learning Management System) is designed to deliver, manage, and track structured training programs. It is commonly used for onboarding, compliance training, certifications, and mandatory learning. An LXP (Learning Experience Platform) focuses on personalized, learner-driven development. It recommends relevant content based on each employee’s skills, interests, and learning goals, helping support continuous learning beyond required courses. When should an organization choose an LMS? An LMS is the right choice when training must be standardized, assigned, and documented. It is particularly valuable for organizations operating in regulated industries where compliance, certifications, reporting, and audit-ready records are essential. Healthcare, financial services, manufacturing, and aviation are common examples. When is an LXP a better option? An LXP is best suited for organizations that want to encourage continuous learning and employee development. It works particularly well when employees are expected to build new skills independently, access learning from multiple sources, and receive personalized recommendations based on their interests and career goals. Can an LMS and an LXP work together? Yes. Many organizations use both platforms as part of the same learning ecosystem. The LMS manages mandatory training, compliance, and certifications, while the LXP supports self-directed learning, knowledge sharing, and continuous skills development. Together, they provide a more complete learning experience than either platform alone. Can an LXP replace an LMS? In most cases, no. While an LXP offers a better experience for personalized learning, it typically lacks the governance, reporting, certification management, and compliance capabilities required for mandatory corporate training. Organizations with regulatory obligations usually continue to rely on an LMS while adding an LXP to support employee development. How is AI changing LMS and LXP platforms? Artificial intelligence enhances both platforms in different ways. In LMS platforms, AI automates tasks such as content tagging, adaptive assessments, reporting, and predictive analytics. In LXP platforms, AI improves personalization by recommending learning content based on each employee’s role, behavior, interests, and skills. The greatest value comes from combining AI with high-quality, well-governed learning content. Which platform is better for compliance training? An LMS is the better choice for compliance training because it provides structured learning paths, completion tracking, certification management, automated reminders, and audit-ready reporting. These capabilities help organizations demonstrate compliance with internal policies and external regulations. How do you choose the right learning platform? The right choice depends on your organization’s goals. If your priority is regulatory compliance and standardized training, an LMS is usually the best option. If your goal is to build a culture of continuous learning and personalized employee development, an LXP may be a better fit. Many organizations achieve the best results by combining both platforms to support different learning objectives.
Read
AI End-to-End Testing: Complete Guide for 2026
Software testing has never been more demanding. Applications are larger, release cycles shorter, and user expectations higher than ever. QA teams are under pressure to validate complex workflows across layered tech stacks, often while fighting fires caused by tests that break the moment a developer pushes a UI update. AI end-to-end testing is changing that dynamic in a meaningful way, not by patching over old problems, but by rethinking how testing works from the ground up.
Read
GPT-Powered AI Agents: How to Match Autonomy to the Process?
Until recently, enterprise automation followed a simple division: systems performed tasks defined by rules, while cases requiring interpretation were passed to people. GPT-powered AI agents expand the range of processes that can be supported through automation. They can work with documents, incomplete data and the language used by customers or employees, making them suitable for processes that were previously difficult to automate. For large organisations, this raises a practical question about AI agent autonomy: where does expert support end, and where does independent action within a process begin? In some situations, the agent’s role is to gather information and prepare a recommendation. In others, it prepares an action for approval. There are also areas where it can independently carry out repetitive steps when the organisation has defined the rules, permissions, limits and exception-handling paths. GPT-powered AI agents can already support teams with ticket handling, document analysis, decision preparation, data updates and multi-step tasks. The key implementation question is: which decisions and actions should remain with people, and which can an agent perform within agreed rules? An AI agent in the enterprise is a process participant, not just a chatbot In practice, a GPT-powered agent needs five elements: access to reliable sources of knowledge, a clearly defined business objective, tools and integrations with enterprise systems, permissions aligned with its role, rules that define the boundaries of its actions. A language model can interpret the content of a document, a customer message or an incident description effectively. It does not, however, replace a business process. Workflows, permissions, validations and decision history are what make an agent operate predictably, even when it handles hundreds or thousands of cases each month. Three levels of AI agent autonomy In a large organisation, it is worth designing agents across three levels. This allows autonomy to grow alongside process maturity and trust in the solution. Operating level Agent’s role Example tasks Human role Level 1: Advisory agent Analyses information and prepares a recommendation. Case summary, risk identification, proposed response, ticket prioritisation. Makes the decision and carries out the action. Level 2: Agent preparing an action for approval Completes the next steps in a process, stopping before actions with significant consequences. Creates an application, updates data, prepares a communication, submits an instruction for approval. Reviews and approves specified steps. Level 3: Agent performing tasks automatically Independently carries out tasks in line with the process policy. Case classification, status updates, sending standard information, creating a task in a system. Handles exceptions, monitors quality and updates process rules. The level of autonomy does not need to apply to the entire agent. The same agent may independently classify tickets, prepare a response that requires approval and transfer unusual cases to an expert. In practice, an organisation therefore designs autonomy for individual decisions and actions, rather than choosing a single operating model for the whole solution. What determines whether an AI agent can complete a task independently? A useful starting point is to assess two factors: the impact of the action on the organisation and whether it can be reversed. The greater the business, legal, financial or reputational consequences of a decision, the more important human approval becomes. Nature of the action Recommended model Low impact, simple rules, easy to reverse Automatic execution with a record in the process history. Medium impact, data from several sources, possible exceptions The agent prepares the action and an authorised person approves it. High financial, legal or customer impact The agent presents analysis, options and justification. The decision remains with a person. Unclear rules, incomplete data or conflicting information Automatic escalation to an expert, together with the context and collected data. This principle is particularly useful in organisations operating across multiple countries, with complex permission structures and a large number of systems. Just as important as the list of tasks is knowing what the agent must not do and when it should hand a case over to a person. 7 questions to ask before giving an AI agent permission to act What action should the agent perform? Describe it specifically, for example: “create a service ticket”, “update contact details” or “prepare a response to a complaint”. What data will it work with? Identify the sources, data owners, update frequency and access rules. What business rules must it follow? These may include financial limits, contractual terms, SLA levels, compliance requirements or communication policies. What exceptions should stop the process? The agent needs a clear escalation path for unusual or incomplete cases, or those requiring specialist assessment. Can the action be reversed? The ease of correction affects the appropriate level of autonomy, the scope of testing and the need for additional approval. Who is accountable for the decision? The process owner, approver and technical team should all have clearly assigned roles. How will the organisation establish why the agent took a particular action? The case history should show the input data, rules, sources used, recommendation and process outcome. This is why AI agent projects often begin with bringing the process itself into order. The organisation gains more than a new AI capability: it also gains better visibility of responsibilities, exceptions and how work actually flows. Where can GPT-powered AI agents add value in a large enterprise? Customer service and back-office teams An agent can read a customer message, identify its subject, retrieve data from a CRM or case-management system, prepare a response in line with company policy and route it to the appropriate queue. For standard cases, it can also update a status, create a task for the team or send the customer a confirmation. Full autonomy works well for low-risk actions, such as providing information about the status of a ticket. Complaints, individual commercial terms or cases requiring interpretation of a contract should be passed to an employee together with the agent’s analysis. Finance, procurement and document workflows An AI agent can read a document, check whether the data is complete, compare it with a purchase order and flag discrepancies that require clarification. It can also prepare a case summary, collect missing information and initiate the appropriate approval workflow. Decision thresholds are particularly important in this area. The agent can process a document automatically when it meets all conditions, while cases that exceed a defined amount, contain discrepancies or concern a new supplier can be submitted for approval. IT, administration and ticket management In an IT environment, an agent can classify tickets, create an incident summary, search for similar cases in the knowledge base, propose actions in line with a runbook and update the user on progress. In administrative processes, it can prepare an application, complete data in a form and remind the requester about missing documents. For actions involving configuration changes, access permissions or production systems, an approval-based model is advisable. The agent reduces the time needed to prepare a decision, while the administrator retains control over the change. Sales and commercial information management An agent can prepare a briefing before a meeting by bringing together information from the CRM, proposals, correspondence and notes, then highlighting open points and suggested next steps. After the meeting, it can create a summary, propose data updates and prepare tasks for the team. These are extensions of scenarios already familiar from everyday work with generative AI. Read more about what the current generation of models helps teams achieve in our article: GPT-5.6 from OpenAI: capabilities and business applications. Why does an AI agent need a workflow? An AI agent can interpret information and suggest next steps, but the process should define the sequence of actions, required validations and the people responsible for approval. In a large organisation, this is what determines the repeatability and scalability of the solution. A process automation platform can act as a control layer: it triggers a task, provides the agent with the necessary context, receives the result, records the history and routes the case to the next stage. The agent then becomes part of a controlled workflow rather than operating as a separate tool outside the core process. This approach is relevant to document workflows, request handling, HR processes, procurement and administration. See how WEBCON BPS can support the digitalisation and control of business processes, and how TTMS delivers process automation. Four forms of human oversight of an AI agent Human-in-the-loop is a model of control embedded in the process—from reviewing recommendations to handling exceptions and making decisions with greater impact. In a mature solution, people can play several different roles. Approving an action when the agent has prepared a specific instruction, communication or system change. Selecting an option when the agent has presented several possible solutions and their consequences. Handling an exception when a case falls outside the agent’s rules, available data or permissions. Overseeing process quality by analysing errors, rejected recommendations, completion times and changing business needs. The most effective implementations use all four forms. The team does not manually review every standard operation, yet retains full control over actions with greater significance and over the direction in which the process evolves. It is also worth observing whether human approval genuinely improves process safety or simply moves a bottleneck elsewhere. If an approver nearly always accepts the agent’s proposals without changes and the cases are easy to reverse, the organisation can consider automating the selected step. If recommendations often require correction or the approver needs to return to source data, this indicates that the process rules, quality of knowledge or scope of the agent’s permissions need attention. When can an AI agent act automatically? Automation delivers the most value when a task is frequent, has a repeatable structure, relies on available data and leads to a clearly defined outcome. It is also important to ensure that execution can be verified and corrected when data or rules change. Good candidates include ticket classification, routing requests to the appropriate queue, completing data from approved sources, creating standard tasks, updating statuses and sending communications based on approved templates. Combining GPT models with an enterprise knowledge layer, integrations and security rules provides a significant advantage. This allows the solution to work with information available to a specific role, rather than with an unstructured collection of documents and conversations. When should an AI agent primarily provide advice? An advisory role is especially valuable in cases that require contextual assessment, interpretation of company policy, negotiation, an individual approach to a customer or decisions with significant financial and legal consequences. In these situations, the agent can gather facts, summarise documents, identify missing information, compare options and prepare the rationale for a recommendation. The person gains time for business judgement, while the decision remains grounded in the knowledge, experience and accountability appropriate to the role. This model is particularly useful for managers, compliance specialists, legal teams, strategic procurement, finance teams and teams responsible for key accounts. FAQ What is the difference between an AI agent and a chatbot? A chatbot primarily responds to questions in a conversation. An AI agent can also use approved tools, retrieve information from enterprise systems, follow workflow rules and complete defined process steps. Its value comes from combining language understanding with access to business context, permissions and a controlled process. Should every AI agent have human approval before taking action? No. The appropriate level of oversight depends on the impact and reversibility of the action. Low-risk, repeatable activities such as categorising tickets or sending a standard confirmation can be automated under defined rules. Actions affecting customers, contracts, finances, compliance or production systems should usually include approval or escalation to an authorised person. Can one AI agent operate at different levels of autonomy? Yes. Autonomy should be designed for individual actions rather than assigned to an entire solution. The same agent may classify a request automatically, prepare a response for approval and escalate an unusual case to an expert. This makes it possible to automate safely without treating every task in the same way. What information does an AI agent need to work reliably in an enterprise? An agent needs access to reliable and current knowledge sources, a clearly defined objective, appropriate permissions and rules for handling exceptions. It should also receive only the context relevant to the task and role. Workflows, validations and an auditable history of actions help ensure that its output can be reviewed and used consistently. How can a company start implementing GPT-powered AI agents? Start with one clearly defined process step that has measurable volume, repeatable inputs and a known outcome. Set the boundaries of the agent’s permissions, test it with standard and exceptional cases, and measure the effect on process time, quality and escalations. Once the team has evidence that the solution works reliably, its scope and autonomy can be expanded gradually.
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
ChatGPT 5.6 in Practice: Initial Compliments and Disappointments
OpenAI rolled out GPT-5.6 in stages. It first appeared in limited test access for selected partners. Access to ChatGPT 5.6 reached Europe, including Poland, gradually, so only recently have teams been able to test the model in everyday work. Expectations are high. In the second half of 2026, businesses expect language models to handle multi-step tasks and work with extensive context. Ease of use matters too. GPT’s interface has undergone a major redesign. Has it improved the user experience and the quality of responses? This article explores that question, as well as: which business processes ChatGPT 5.6 can support by improving productivity and the quality of working materials, how to plan an AI pilot in your organisation, measure results and maintain quality control, which limitations of ChatGPT 5.6 to consider before a wider rollout, how to establish a shared standard for prompts and output validation across the team, what early users think about working with ChatGPT 5.6. If you are looking for a full overview of the changes, pricing, models and capabilities of GPT-5.6, see our article GPT-5.6 from OpenAI: what has changed, pricing, capabilities and business applications. ChatGPT 5.6: our first impressions and early industry feedback Early expert reviews focus primarily on context handling. Reviewers note that when working with substantial material that goes through multiple rounds of edits, ChatGPT 5.6 is better at keeping the task on track. Most of us have experienced earlier OpenAI models losing their “bearing”. On top of that, the model itself encouraged endless revisions, which could pull the material away from the original intent of the prompt. GPT 5.5 had an irritating habit of suggesting more and more variations. Almost every response ended with a clickbait-style suggestion along the lines of: “If you want, I can help you add two elements that will create a wow effect and give the text around 50% more SEO power.” As a result, instead of closing the topic, we were drawn into the model’s endless doubts: could the material really not be improved further? GPT 5.6 is no less capable than the older model, but it finally respects what matters most: the intent behind the prompt and our time. Kajetan Terlecki SEO Specialist, TTMS Another recurring observation concerns the quality of the first draft—the material GPT produces after the first prompt. Reviewers emphasise that the model’s draft is usually well structured and much closer to a final version than it was with GPT 5.5. It is not a perfect ten yet, but a solid eight. In other words, a final version may be within reach after a relatively short time. With earlier GPT models, the “brainstorming” phase took much longer. The third—and most immediately noticeable—area is the way we use the tool, which we can simply call the “interface”. It is admittedly quite complex. Beyond writing a prompt, users must make a series of decisions: which workspace should I choose: Chat or Work? which model best fits my request: Luna, Terra or the most advanced Sol? Or is the older GPT 5.5 enough? does the task require Deep Research? how much effort should the model put into the task: low, medium, high, very high, max or ultra? should I use Turbo mode and generate a response 50% faster at the cost of higher token use? If we add the almost endless range of available plugins, writing the prompt turns out to be only half the work required to get a useful result. I would welcome an automatic mechanism that reads the prompt and selects the right settings on its own. One that uses a sufficiently capable GPT model without wasting tokens when they are not needed. How do you navigate all this? We have outlined a suggested configuration here, including which modes to use for different types of tasks. Where does GPT 5.6 outperform the previous version? 1. GPT 5.6 is better at preserving document layout and formatting The previous version of GPT had something of a goldfish memory. You could also compare it to a short blanket: pull it over one part, and another is left exposed. When we asked the model to update data in a document it had generated, it produced a factually correct response, but one that no longer followed the original format. It might use a different heading hierarchy, rearrange the information or omit elements that are essential for the company. GPT 5.6 is much better at preserving the structure of reference material. OpenAI illustrated the difference in materials introducing GPT-5.6. The company placed three slides side by side: the reference file, the GPT-5.5 output and the GPT-5.6 output. The task was to update figures in a presentation while retaining the original template. In the comparison, GPT-5.5 omitted some template elements, while GPT-5.6 preserved the slide structure more faithfully: layout, typography, spacing, colours and recurring template elements. OpenAI states that GPT-5.6 can also interpret rules saved in the slide template, including the Slide Master. In practice, this matters when a presentation needs to retain not only its colours and fonts, but also defined layouts, spacing and mandatory components. 2. GPT-5.6 moves beyond the chat window GPT-5.6 shows its greatest potential when it works not only with a single instruction, but also with files and tools made available by the user. It can then move quickly through a task: from gathering the materials to preparing a first draft. The new GPT model can identify related files in a project folder, flag places that need updating and prepare working versions of documents. There is a catch: the process still needs human oversight. Someone must check whether GPT found all the relevant files, understood the context correctly and left unchanged the elements that were meant to remain unchanged. Still, instead of manually digging through documents, the team starts with a list prepared by the model. 3. From an idea to a version you can show the team Experts testing GPT 5.6 point out that the first version of a simple application, dashboard or website is now more often suitable for showing to a team and collecting specific feedback. It is somewhat like an MVP: good enough to test an idea, present it to the team and gather initial comments. A product owner can see the whole process, a designer can assess the layout and usability, and a developer can spot technical constraints sooner. This does not mean that GPT-5.6 creates a finished product. The initial prototype still needs to be assessed for security, quality and architecture. The difference is concrete, however: the team can evaluate an actual solution earlier, rather than debating assumptions alone. 4. GPT 5.6: “I don’t know” — is this the end of answers given for the sake of answering? We all know the old classified ad: “Encyclopaedia Britannica, 40 volumes for sale. I got married a week ago, so I no longer need it. My wife knows everything better.” The know-it-all syndrome is a nuisance not only in old marriage jokes, but also for people who work with language models every day. GPT often lacks the information needed to give a reliable answer. GPT-5.5, like earlier versions, would rather provide an incorrect—yet convincing-sounding—answer than admit it did not know. What about the new version? The change is visible at first glance, even though it is hard to capture in a benchmark and easy to appreciate in day-to-day work. Our first days of working with the two most advanced models, Terra and Sol, suggest that GPT 5.6 is more likely to say “I don’t know”, “I don’t have enough data” or “I could not find anything else on this topic”. People still need to add or verify information manually, but this reduces the risk of an embarrassing error in material prepared for a client, the board or a project team. Before you give GPT-5.6 an important task: what to watch out for in early testing 1. A working prototype is not yet a finished product GPT-5.6 can prepare a website, dashboard or simple application that can be launched and shown to the team. This is a major step forward, particularly when testing an idea. The tests also reveal the other side: elements can become misaligned, interactions do not always work as intended, and visual details still require refinement. The first version can be an excellent starting point, but it should not automatically be sent to clients or other external audiences. Before treating it as finished, we need testing, a security assessment and, in some cases, a developer’s review. 2. The new Work environment can still be frustrating Model quality is one thing. The way we use it in practice is another. One reviewer pointed out that, in Work, it was difficult to access generated files and open a preview of the finished result. Others criticised the number of settings—discussed earlier in this article—as well as the unclear distinction between Chat, Work and Codex. GPT-5.6 may complete a task correctly, while the working environment still makes it difficult to retrieve or review the result. It is worth testing the entire process, not only the quality of the response in the chat window. 3. GPT needs clear boundaries One reviewer tested how GPT-5.6 would handle a complex mathematical problem. The model produced correct parts of the solution, but surrounded them with definitions, digressions and comments that added little value. Only after the instruction was made more specific did it produce a useful result. The same applies in a business context. We should not leave the model too much room for interpretation. It is better to state the expected result directly: “Prepare a one-page summary. Include the decision, three arguments, risks, missing information and next steps.” GPT then has fewer opportunities to pad the topic with peripheral content. 4. GPT can still be wrong The fact that GPT-5.6 appears more likely to signal that it lacks data or a basis for drawing a conclusion does not mean it is free from hallucinations. Luna, Terra and Sol—with Sol seemingly the least prone to this—can still provide an incorrect date, number, source or conclusion without batting an eyelid. The rule to “check after AI” still applies and will likely remain relevant for many future GPT releases. 5. Start with one problem, not a large system Once GPT-5.6 has access to files, a browser and company tools, it is easy to imagine a system that instantly organises the inbox, analyses team communication, updates the CRM and writes responses to clients. This vision can quickly turn into a project larger than the problem it was meant to solve. One expert working with an extensive Codex environment recommends starting with a single, repeatable task. It might be preparing a meeting summary, gathering open project issues or updating an offer after data changes. Only once the team sees measurable results and understands the tool’s limitations is it worth adding further automations. How should you run your first ChatGPT 5.6 test in the company? A pilot should answer one straightforward question: does GPT-5.6 genuinely improve a selected stage of work, and does the benefit justify the time, cost and additional quality control? The first test should not begin with building an extensive automation system. It is better to choose one repeatable task that currently takes up the team’s time and has a clearly defined outcome. This might be a meeting summary, a brief or a status report. What matters is that the team knows which materials it provides to the model, what result it expects and who reviews the final document. Before starting the pilot, answer five questions: Choose one process: for example, preparing meeting summaries, sales briefs or materials for project decisions. Set a baseline: measure the time needed to prepare the material, the number of revisions, the number of people involved and the most common errors. Prepare a shared prompt: use the same input materials and clearly describe the outcome the team expects. Assign expert review: nominate a person who will verify the facts, assess quality and approve the result before it is used further. Assess the outcome: compare time, the number of iterations, completeness of the material and the usefulness of the result for the next stage of the process. Pilot element Question for the team Process Which stage of work do we want to shorten or organise? Outcome What should be produced: a brief, decision list, analysis, recommendation or communication draft? Data Which materials are needed, and can they be used in the selected AI environment? Quality control Who confirms the facts, completeness and alignment of the material with the process? Metric How will we compare working time, the number of revisions and the usefulness of the result? After a few attempts, it becomes easier to assess whether the model is genuinely helping. Compare the time needed to prepare the material, the number of revisions and the effort required to verify the result. Only then decide whether to extend the pilot to further tasks. Three processes worth starting with 1. Summaries after client meetings The model can organise notes, gather decisions, identify open questions and prepare a list of next steps. The team confirms the arrangements and assigns task owners. This helps them move from discussion to action more quickly. 2. A brief for a sales conversation Based on selected sales materials, previous arrangements and public information about the company, GPT-5.6 can prepare a brief, discovery questions and a list of topics that require clarification. The salesperson remains responsible for the client relationship and decisions regarding the offer. 3. A status report for the project team The model can organise information about progress, blockers, risks and planned actions. The project owner confirms that the information is up to date before the report is shared further. This reduces the time the team spends manually consolidating data from several sources. How do you embed AI in a business process? After the pilot, it becomes clear whether ChatGPT 5.6 genuinely shortens the preparation of materials, reduces the number of revisions and helps the team move more quickly to the next stage of work. It also reveals where the model needs a better brief, access to data or expert oversight. Proven use cases can then be extended to other processes. At this stage, it is worth addressing data security, integration with existing tools, output quality and a clear division of responsibilities. These factors determine whether AI becomes lasting support for the organisation. At TTMS, we help organisations identify processes where automation and AI create business value. We then design solutions tailored to their data, regulatory requirements and ways of working. We combine engineering experience with a responsible approach to AI governance, confirmed by ISO/IEC 42001 certification. Let’s discuss the processes AI could support in your organisation. FAQ How do you choose a process for your first ChatGPT 5.6 test? The best candidate is a repeatable process that requires gathering several pieces of information and producing a predictable result. Examples include meeting summaries, sales briefs, status reports and document analysis. The team should know the current turnaround time and typical issues, as these provide the baseline for assessing the test. Start with one process and expand the use of AI only after evaluating the outcome. How do you measure the business value of ChatGPT 5.6? During a pilot, measure the time needed to prepare the first version of the material, the number of revisions before approval, the completeness of the output and the expert time required for verification. It is also useful to track metrics related to the next stage of the process – for example, faster meeting preparation, a shorter time to close agreed actions or fewer missing details in a report. This data helps assess team productivity based on actual results and supports decisions about integrating AI into further processes. What data should you prepare for working with ChatGPT 5.6? The model produces better results when the team provides current, well-organised source materials. Before starting, identify which documents take priority, which data must remain unchanged and how unverified information should be marked. The organisation should also define which data can be shared in the chosen AI environment. For personal, financial and confidential data, access rules, retention and compliance are essential. How do you maintain human oversight of the model’s work? Human oversight should be part of the process from the start. The process owner defines the task scope, an expert verifies facts and alignment with requirements, and an authorised person approves external actions. This division of responsibilities is particularly important for client communication, publications, data changes in systems and materials with legal or financial implications. It allows the team to use automation while retaining responsibility for the outcome. Where can I find information about GPT-5.6 pricing, models and capabilities? We have covered the changes in GPT-5.6, pricing, the Sol, Terra and Luna models, and business applications in a separate article: GPT-5.6 from OpenAI: what has changed, pricing, capabilities and business applications. This article focuses on the practical use of ChatGPT 5.6 in team workflows, early user experiences and how to run an AI pilot in an organisation.
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.
ReadThe world’s largest corporations have trusted us
We hereby declare that Transition Technologies MS provides IT services on time, with high quality and in accordance with the signed agreement. We recommend TTMS as a trustworthy and reliable provider of Salesforce IT services.
TTMS has really helped us thorough the years in the field of configuration and management of protection relays with the use of various technologies. I do confirm, that the services provided by TTMS are implemented in a timely manner, in accordance with the agreement and duly.
Ready to take your business to the next level?
Let’s talk about how TTMS can help.
Sunshine Ang Sen Shuen
Sales Manager