Home •Blog
TTMS Blog
TTMS experts about the IT world, the latest technologies and the solutions we implement.
Sort by topics
Search results for the term: “TEAMS”
Microsoft Teams raises the bar
With their subsequent activities, the creators of Teams consistently confirm that remote work – and ultimately hybrid work – is not a replacement model or a temporary fashion. It is a space taken seriously by Microsoft, to which it is worth delivering technological investments both at the code and hardware level.
ReadMS Teams dynamic view
We wrote about the tendency to “humanize” remote work last year (see article here). In March 2021, the MS Teams platform will follow this trend, presenting its new, more interactive version. Dynamic view – this is the name of the new interface after “tuning”.
Read
Salesforce and Teams integration – cooperation or competition?
#Teams and #salesforce tags in one post? It is fully justified, because from today Salesforce functions as an application, integrated with the Microsoft Teams platform, although both parties still cautiously call it “pilot”. It’s hard to talk about a surprise here, because previously the CRM software vendor chose Microsoft Azure as the cloud provider.
ReadMS Teams – a creature that lives. Interview with Jarosław Szybiński (TTMS)
What would you improve in Microsoft Teams? – Working with Teams and Office 365 is a bit like a paranoid dream. Microsoft continues to add, improve and change features. Sometimes I don’t know, if there was something missing yesterday or if it’s just my imagination – says Jarosław Szybiński, Business Development Manager at Transition Technologies […]
Read
AI in Software Test Automation – 2026 Guide
AI in software test automation is moving beyond isolated experiments and becoming part of broader QA and engineering workflows. Teams are using it to support test design, verify scenarios, generate automation code, analyze execution results, and reduce repetitive maintenance work. The value, however, depends on how these capabilities are introduced and governed. This guide explains where AI can support the test automation lifecycle, what organizations should evaluate before adopting a platform, and how to maintain control over test intent, generated code, execution evidence, and ongoing optimization. 1. AI in Software Test Automation: Why It Matters in 2026 As applications and delivery processes become more complex, test automation must cover more than the execution of predefined scripts. Teams also need to keep tests aligned with changing requirements, maintain automation assets, interpret execution results, and decide which scenarios require attention. AI can support these activities by connecting requirements, test design, execution evidence, code generation, and maintenance signals. The value comes from reducing repetitive work while preserving clear ownership, review, and traceability across the test automation lifecycle. For organizations adopting AI in software test automation, the priority in 2026 should be building a controlled workflow rather than adding isolated AI features. Generated outputs need reliable project context, execution-based verification, defined approval gates, and integration with existing repositories and CI/CD processes. 2. What Is AI in Software Test Automation? AI in software test automation refers to the use of capabilities such as natural language processing, contextual analysis, pattern recognition, and AI agents to support the creation, execution, verification, and maintenance of automated tests. Depending on the platform, AI can support different stages of the test automation lifecycle, from interpreting requirements to generating and maintaining automated tests. 2.1 How AI-Powered Testing Differs from Traditional Test Automation Traditional test automation executes predefined scripts according to explicitly programmed steps, conditions, and assertions. This provides predictability and technical control, but creating and maintaining the scripts can require significant engineering effort as requirements, interfaces, test data, and application behavior change. AI-powered testing adds a contextual layer to this process. It can interpret requirements, use project knowledge to prepare test scenarios, support execution-based verification, generate code, and analyze feedback from test runs. Depending on the implementation, AI may also identify unstable tests, suggest updates, or highlight gaps in coverage. The difference is not that AI removes scripts or human involvement. AI-assisted workflows can reduce the manual effort between a requirement and working automation, while QA remains responsible for test intent and engineering retains control over the code entering the repository. 3. Where AI Supports the Test Automation Lifecycle AI in test automation is not a single capability. Understanding its role at each stage of the testing lifecycle helps teams evaluate platforms more accurately and set realistic expectations for adoption. Understanding these capabilities separately helps teams evaluate platforms more accurately and decide where AI can provide useful support without removing human review and technical control. 3.1 Requirements and Test Design AI can translate requirements, acceptance criteria, tickets, and existing QA knowledge into structured test scenarios. This reduces the manual effort involved in turning business requirements into detailed test cases and can help teams identify missing preconditions, expected results, or alternative paths. The quality of the output depends on the available project context. Generated test cases should therefore remain reviewable and should clearly distinguish confirmed information from gaps that require input from QA or business stakeholders. 3.2 Execution-Based Verification A generated test scenario may appear correct while still being impossible to execute against the actual application. Execution-based verification allows an AI agent to replay the proposed steps, observe application behavior, identify relevant elements, and confirm whether the expected result can be reached. This creates technical evidence before automation code is generated. QA still needs to confirm that the verified path represents the intended business scenario. 3.3 Automation Code Generation AI can use test intent and execution evidence to generate automation code. The output should follow the project’s existing conventions, use its reusable components, and remain readable for the engineering team. Generated code should be tested and delivered through the organization’s normal version control and review process. This keeps automation visible, reviewable, and maintainable instead of isolating it inside a proprietary environment. 3.4 AI-Assisted Test Maintenance and Optimization AI can analyze execution history, recurring failures, unstable assertions, selector changes, and overlapping coverage to identify tests that may require attention. It can then recommend repairs, consolidation, or removal. Significant updates should remain visible and subject to review. An automatically modified test may continue to pass while no longer validating the original requirement, so maintenance decisions need clear ownership and approval. 3.5 Reporting, Traceability, and Review AI can help organize execution evidence and connect results with the relevant requirement, test case, code change, and review decision. This gives QA and engineering teams a clearer view of what was tested, how the automation was created, and why it changed. For enterprise use, teams should be able to inspect AI inputs, generated outputs, execution results, and reviewer decisions rather than relying on an opaque automation process. 4. Where AI Creates Business Value in Test Automation AI creates business value in test automation by shortening the path from a requirement to reviewable automation. It can reduce the manual work involved in interpreting tickets, drafting test scenarios, translating test intent into code, and analyzing execution results. This allows QA professionals to contribute their domain knowledge more directly to automation, while engineering teams focus on technical review and repository standards instead of building every test from scratch. The result can be faster automation delivery without creating a separate handover for every scenario. Greater traceability also helps teams understand how test intent becomes automation and whether later changes still reflect the original requirement. The value depends on implementation quality. AI-generated outputs still require reliable project context, execution-based verification, clear ownership, and review before they enter the test suite. Organizations should measure success through reduced manual effort, shorter time from requirement to reviewed automation, acceptance of generated code, lower maintenance effort, and more dependable execution results. 5. How to Evaluate and Integrate an AI Test Automation Platform Choosing an AI testing platform requires more than comparing feature lists. The platform should fit the team’s existing requirements workflow, automation frameworks, repositories, CI/CD processes, security policies, and technical skills. Decision-makers should begin with the workflow they want to support. A platform designed only to generate test cases may not solve the wider challenge of turning requirements into executable, maintainable automation. Teams should evaluate how the tool handles test design, execution-based verification, code generation, review, reporting, and ongoing maintenance. 5.1 Key Criteria for Evaluating an AI Test Automation Tool When evaluating an AI test automation tool, consider: Requirement integration: Can the platform use tickets, acceptance criteria, and existing QA knowledge as test context? Execution model: Does it verify proposed scenarios against the application before generating automation? Code ownership: Does the output remain accessible as standard code in the organization’s repository? Review and governance: Can teams inspect AI inputs, generated outputs, execution evidence, and reviewer decisions? Framework compatibility: Does the platform support the automation technologies already used by the organization? Repository alignment: Can generated code follow existing fixtures, helpers, hooks, naming rules, and quality standards? Deployment and data control: Can the platform operate within the organization’s required infrastructure and AI governance model? Maintainability: Does it use execution feedback to identify unstable, outdated, or redundant automation? Team fit: Can QA define and review test intent while engineering retains control over code quality? These criteria help distinguish a complete AI test automation workflow from an isolated generation feature. 5.2 Fitting AI Testing into Your CI/CD Pipeline An AI testing platform should work with the organization’s existing version control and CI/CD processes. Generated automation should enter the repository through the normal pull or merge request workflow, where it can be reviewed, executed, and approved before being merged. Execution results should return to the relevant code change, test case, and requirement source. This creates traceability between test intent, automation code, execution evidence, and release decisions. Integration may require repository access, execution environments, credentials, pipeline configuration, and approval gates. These requirements should be assessed during implementation rather than assuming the platform can be added without changes to the existing delivery architecture. 6. How to Adopt AI Test Automation with the Right Controls A practical AI test automation strategy should begin with one clearly defined workflow rather than an attempt to automate the entire testing process. Choose a repeatable, business-critical user journey, document the current effort and maintenance burden, and define what successful adoption should improve. Start with requirements and test cases that have clear preconditions, actions, and expected results. AI output depends on the quality of this context, so incomplete requirements and inconsistent testing conventions should be addressed before the workflow is scaled. Define ownership and approval gates from the beginning. QA should remain responsible for test intent and business relevance, while automation engineers or developers review generated code, repository alignment, and technical quality. AI-generated automation should not enter the test suite without execution-based verification and the required human approval. Implementation should include the technical and governance work required to connect the platform with repositories, execution environments, CI/CD, models, and reporting processes. Finally, track practical outcomes such as the time from requirement to reviewed automation, the number of generated tests accepted with limited changes, maintenance effort, recurring failures, and user adoption. Expand to additional workflows only after the initial process is stable, reviewable, and understood by the teams responsible for maintaining it. This shift changes how QA, automation, and engineering teams collaborate, a topic explored further in our guide to how AI is changing the work of developers, testers, and analysts. 7. Challenges and Limitations of AI in Test Automation AI in test automation depends heavily on the quality of the requirements, project context, test data, and repository conventions available to the platform. Incomplete or inconsistent inputs can lead to scenarios that are technically executable but do not reflect the intended business behavior. Execution-based verification can confirm that a proposed path works against the application, but it cannot independently determine whether the path represents the correct test intent. QA still needs to review the scenario, expected result, and alignment with the original requirement. Generated automation may also require adjustment to match project-specific fixtures, helpers, authentication methods, data setup, and coding standards. Teams should expect an implementation and review process rather than treating AI test automation as a plug-and-play capability. Security and governance create additional requirements. Organizations also need clear controls over deployment, model usage, data access, generated code, and approval of AI-supported changes, especially in business-critical or regulated workflows. The strongest implementations use AI to reduce repetitive work while keeping responsibility for test intent, code quality, and release decisions clearly assigned. For a broader view of risk-based testing, traceability, and quality governance, see our QA best practices guide. 8. How Qatana Brings AI Test Automation into One Controlled Workflow Qatana brings test design, execution-based verification, code generation, review, and maintenance into one agentic test automation workflow. It starts with requirements from Jira or GitLab, turns them into automation-ready test cases, and verifies the proposed user path through Playwright execution before generating code. The resulting standard Playwright code is delivered through a pull-ready merge request. QA retains control of test intent, while engineering reviews the technical implementation through the organization’s existing version control process. Execution results remain linked to the requirement, test case, code, and review history, providing traceability across the workflow. Qatana also uses execution results, CI/CD signals, and reviewer feedback to support test maintenance and optimization. The platform runs entirely on-premise and supports the organization’s selected LLM, keeping project context, generated code, and execution evidence within the customer’s controlled environment. Book a demo to see how Qatana turns requirements into execution-validated Playwright automation. 9. Frequently Asked Questions About AI in Software Test Automation Can AI fully replace manual testers? No. AI can support test design, execution, code generation, and maintenance, but testers still define business intent, review outputs, and perform exploratory testing that requires human judgment. How does AI improve self-healing test automation? AI can detect changes affecting automated tests and suggest or generate updates based on execution evidence. Significant changes should remain visible and require review to ensure the test still validates the intended behavior. Is AI-driven testing suitable for regulated industries? Yes, provided the platform supports appropriate governance, traceability, access control, and data protection. Organizations should also evaluate deployment options, model control, audit evidence, and internal compliance requirements. What skills do QA teams need to work with AI testing tools? QA teams need strong test design, domain knowledge, and the ability to review AI-generated scenarios and execution evidence. Familiarity with automation workflows, repositories, and AI limitations is also valuable.
Read
SaaS validation in pharma and GxP requirements
A SaaS application can support quality processes, laboratory work, manufacturing, distribution or clinical operations without requiring the customer to maintain the application in its own data centre. The cloud delivery model does not remove the regulated company’s responsibility for the way the system is used. If an application processes GxP data, affects product quality or patient safety, or supports regulated decisions, the organisation must demonstrate that it is fit for its intended use and remains controlled throughout its lifecycle. SaaS validation in pharma differs from a conventional implementation project. The supplier controls part of the platform, releases updates on its own schedule and may rely on subcontractors. The customer configures processes, roles, data, integrations and use. Responsibilities are shared, but regulatory accountability for the GxP process remains with the regulated organisation. This guide explains when a SaaS system requires validation, how to build a risk-based strategy, which supplier evidence can be used and how to maintain the validated state through frequent software releases. It focuses mainly on GMP environments. Many of the principles can also support GLP, GCP, GDP and pharmacovigilance systems after the applicable regulations and company procedures have been identified. 1. What SaaS validation means in a GxP environment Computer system validation provides documented evidence that a system meets approved user requirements, performs according to its intended use and is controlled in proportion to risk. In a SaaS model, the object of validation is not the supplier’s product in isolation. It is the customer’s specific use of the application, including its configuration, processes, data, interfaces, user roles and operating procedures. The same product may have a different validation status in two companies. One may use it only to arrange meetings. Another may use it to approve specifications, retain laboratory results or generate a record used in batch release. The product name and supplier claims do not determine the validation scope. Intended use, data criticality and the effect of each function on the regulated process do. In practical terms, the validation programme should answer four questions: Are the business and regulatory requirements clear and approved? Have risks to patients, products and data integrity been identified and controlled? Have the configuration and critical processes been tested effectively? Can the organisation maintain control after go-live? Validation is not a permanent certificate attached to an application. It is an evidence-based state associated with a defined version, configuration and use, and maintained through change control, incident management, access management and periodic review. 2. When a SaaS system falls within GxP scope The first step should be system and function classification, rather than ordering a full set of test scripts. The organisation needs to determine whether the application creates, modifies, stores, transfers or reports data used in regulated activities. It must also consider whether a failure, configuration error or unauthorised change could affect product quality, patient safety, data reliability or process compliance. SaaS applications that may have GxP relevance include: electronic quality management systems and eQMS platforms; document management, learning and training systems; LIMS, ELN and analytical data management platforms; clinical operations, safety and case management applications; systems for change control, deviations, CAPA and complaints; ERP, planning and warehouse systems when their data affect GxP operations; electronic record and signature platforms used in regulated processes. Not every function in such a system has the same criticality. A document approval workflow may require more rigorous controls than a supporting dashboard. A risk-based approach directs testing and documentation towards the functions that affect protected records and regulated decisions. 2.1 GxP impact assessment The impact assessment should identify the regulated process, business owner, record types, decisions made from the data and possible consequences of failure. A single GxP or non-GxP label may be too broad for a system that supports several processes. Function-level and data-flow analysis produces a more defensible scope. Functions are likely to have higher impact when they: control a critical process step or provide data used to release it; generate, calculate or approve a result relevant to product quality; retain original data, metadata and the audit trail; manage electronic signatures or approvals; transfer data between systems without an independent completeness check. The outcome should identify critical requirements, the evidence required and the types of change that will trigger reassessment or regression testing. 3. Regulatory basis for pharmaceutical SaaS validation The primary European reference is EudraLex Volume 4 and EU GMP Annex 11. Annex 11 applies to computerised systems used in GMP-regulated activities. It requires applications to be validated and IT infrastructure to be qualified. Decisions about validation scope and data-integrity controls should be based on a justified and documented risk assessment. Annex 11 does not create a separate legal class for SaaS. The delivery model does not remove obligations relating to supplier assessment, validation, security, audit trails, business continuity, archiving and periodic evaluation. The current EudraLex listing identifies the January 2011 revision of Annex 11 as the applicable published text. EMA guidance on GMP and data integrity expressly includes cloud-based applications and storage within the data lifecycle. An organisation should understand where data and metadata are generated, processed, transferred, stored, retrieved and disposed of, and which parties can access them. Validation effort should be scaled to risk. ICH Q9(R1) on quality risk management states that the level of effort, formality and documentation should be commensurate with risk. This principle does not allow required controls to be reduced for budgetary reasons. It allows evidence to be tailored to function criticality, system complexity and uncertainty. GAMP 5 is widely used as industry guidance for applying a lifecycle and risk-based approach to GxP computerised systems. The ISPE overview of GAMP 5 describes a framework intended to support systems that are effective, reliable and fit for use. GAMP 5 is not legislation and does not certify a product. Each organisation still needs a validation strategy based on applicable regulations, intended use and its pharmaceutical quality system. Where a system supports activities regulated in the United States, the scope of 21 CFR Part 11 and the relevant predicate rules also needs to be assessed. FDA guidance on electronic records and electronic signatures explains that Part 11 applies to specified electronic records maintained or submitted under FDA requirements. Not every electronic function is automatically in scope, and a claim that software is Part 11 compliant does not replace an assessment of the configured process. 4. Responsibilities of the regulated company and SaaS supplier In an on-premises implementation, the regulated organisation may control the servers, database, update schedule and many administrative activities. In SaaS, some of these activities are performed by the supplier or its subcontractors. This changes the sources of evidence and the oversight mechanisms, but it does not transfer accountability for the regulated process. Responsibilities should be recorded in the contract, quality agreement or another controlled document. A standard subscription agreement will rarely address every issue relevant to GxP operation. Area Typical supplier responsibility Regulated company responsibility Expected evidence Product development Controlled development lifecycle, product testing and defect management Assess supplier processes and determine whether available evidence can be relied on Audit or qualification report, SDLC description, test summaries Infrastructure Hosting, platform maintenance, monitoring and technical backups Assess the service model, retention needs and recovery requirements Architecture, responsibility model, recovery test results Configuration Configuration functions and product documentation Approve the configuration required for the GxP process Configuration specification, review and tests Access Role, authentication and access-management capabilities Design roles, provision access and perform periodic reviews Role matrix, test evidence and review records Releases Release communication, product testing and deployment Impact assessment, regression decision and approval for use Release notes, impact assessment and regression tests Data Technical storage, export and protection mechanisms Classify data and control retention, completeness and use Data map, export tests and archiving procedures Incidents Detect and manage service-side events Assess GxP impact, take quality actions and make business decisions Tickets, root-cause analysis, CAPA and decision records The responsibility matrix should not leave gaps or create duplicated duties without a named owner. Particular attention is needed where the supplier assumes that the customer will test a control while the customer considers it part of the standard service. 5. SaaS validation in pharma step by step 5.1 Define the intended use The intended-use statement explains why the organisation is implementing the system, which processes it will support, who will use it and which decisions will rely on its data. It needs to be specific. Describing an application only as a quality management system does not show whether it manages documents, CAPA, training, audits, signatures or all of these functions. The boundary should identify interfaces, source systems, GxP records and functions that remain out of scope. A clear boundary reduces later disputes about testing and accountability. 5.2 Map the process and data lifecycle A process map shows where data are created, reviewed, approved, reported and archived. For SaaS, it should also cover transfers between services, APIs, reporting layers, backups, exports and supplier administration tools. The analysis needs to include metadata required to reconstruct an event. A PDF export may be insufficient when it omits change history, signatures, timestamps, relationships or record context. 5.3 Qualify the supplier and service Supplier qualification should be proportionate to system criticality and dependence on the external service. ISO 27001 certificates, SOC reports and security-test results may provide useful evidence. They do not automatically demonstrate that the customer’s GxP workflow and configuration are compliant. The assessment may cover: the supplier’s quality system and assignment of responsibilities; the software development lifecycle, testing, code review and defect handling; release, change and release-note management; security, vulnerability management and incident response; business continuity, backups and recovery testing; subcontractor oversight and data-processing locations; access to documentation, audit support and data on contract termination. Depending on risk, the organisation may use a questionnaire, document review, remote audit or on-site audit. One fixed method is unlikely to suit every supplier. 5.4 Agree requirements and acceptance criteria The user requirements specification should describe the required outcome and measurable acceptance criteria. Requirements need to be testable and traceable. In addition to business functions, the URS should address data integrity, security, audit trails, electronic signatures, retention, export, performance, availability and failure handling where relevant. A statement such as the system has an audit trail is too broad. The requirement should define which events are recorded, whether the record contains the user, date, time, old and new values and reason for change, and who can review and export the history. 5.5 Assess functional and data-integrity risks The risk assessment links requirements to potential failures and controls. For each critical function, the team should determine what can go wrong, the possible effect, how the failure may be detected and which control reduces the risk. Critical requirements need appropriately strong evidence from testing or another assessed source. Risk assessment should not be reduced to a mechanical multiplication of scores. Rationale, process knowledge and the quality of input information matter more than a superficially precise number. Risk needs to be reconsidered when the configuration, process, interface or supplier changes. 5.6 Design the configuration and controls Standard SaaS configuration can reduce the need for custom code, but configuration can still determine how a regulated process behaves. Statuses, approval paths, escalation rules, roles, dictionaries, forms and retention rules should be described, reviewed and controlled. Extensions, scripts, automation and integrations increase the customer’s responsibility. Their owners, repositories, deployment method and test process should be defined. Extensive customisation may also reduce the value of standard supplier evidence. 5.7 Validate migration and interfaces Data migration requires evidence of completeness, accuracy and preservation of record meaning. The strategy should define mapping rules, transformations, rejected records, record-count reconciliation and exception approval. Sampling may be suitable when its scope is justified by risk and data structure. Interfaces should be tested in both directions when two-way flow matters to the process. Tests should cover valid data, transmission failures, duplicates, message retries, time synchronisation and behaviour after a partial failure. 5.8 Test critical processes Testing should demonstrate that requirements are met and controls are effective. Supplier evidence may be leveraged when the organisation understands its scope, version, environment and approval method. There is no value in automatically repeating every product test. The customer must still verify its own configuration, data, interfaces, roles and critical workflows. The test package may include: positive tests of critical business flows; negative tests and exception handling; role and segregation-of-duty tests; audit-trail and electronic-signature verification; data migration and transfer-integrity tests; report, calculation and export tests; failure, recovery and business-continuity scenarios; acceptance tests performed by representative users. IQ, OQ and PQ terminology may be used where it forms part of the organisation’s quality system, but the labels should not replace a logical connection between requirements, risks and evidence. For a typical SaaS service, much of the installation or infrastructure evidence may come from the supplier. The configured use and intended purpose still require customer assessment. 5.9 Approve the validation and go-live decision The validation summary report should identify the system version and configuration, completed activities, test results, deviations, residual risks and release conditions. An open deviation does not always prevent go-live, but risk acceptance needs to be explicit, justified and approved by the appropriate roles. Before release, the organisation should confirm that procedures, support, training, access management, backup arrangements, monitoring and incident handling are ready. Technical validation without operational readiness does not provide sustained control. 6. Validation documentation for a SaaS system The documentation package should provide traceability from intended use and requirements to risks, controls, tests and the release decision. Document names differ between organisations. The important point is whether evidence is complete, approved, current and reproducible during an inspection. Document or record Main purpose SaaS-specific consideration GxP impact assessment Determine whether and to what extent the system is controlled Analyse functions and data flows rather than the product name alone Validation plan Define scope, roles, methods, environments and acceptance criteria Identify supplier evidence and customer activities Supplier assessment Justify reliance on the supplier and service Subcontractors, hosting, SDLC, releases and audit rights User requirements specification Record approved user and regulatory requirements Testable criteria for data, audit trails, signatures and export Risk assessment Link functions to risks and controls Configuration criticality, integrations and automated changes Configuration specification Provide a controlled record of system settings Workflows, roles, rules, extensions and retention settings Test protocols and evidence Demonstrate that requirements are met Version, environment, test data, results and deviations Traceability matrix Connect requirements, risks and tests Identify which evidence originated with the supplier Validation summary report Record the conclusion and release decision Residual risk, conditions and outstanding actions Validated-state plan Define post-release control Release assessment, regression testing, review and retirement Supplier documentation should be accepted deliberately. A supplier test report is useful only when its version, scope, environment, criteria and approval status are understood and relevant to the functions used by the customer. 7. Data integrity and ALCOA principles A SaaS system should support data that can be attributed to an individual, read, associated with the time of the activity, retained as original data or a verified copy and considered accurate. The extended ALCOA+ principles also address completeness, consistency, endurance and availability. The data-integrity assessment should cover: unique accounts and accountability for user actions; time synchronisation and the meaning of time zones; protection of original data and associated metadata; change control and audit-trail review capability; completeness of exports, reports and verified copies; data protection during integration and migration; retention, archiving, retrieval and readability for the required period; data recovery after failure and evidence that restoration works. It is not enough to confirm that an audit-trail feature exists. The organisation should determine whether it is always active for critical events, who can change its settings, how changes are displayed and how it will be reviewed. If supplier administrators have privileged access, their activities also require appropriate oversight. 8. SaaS releases and the validated state The main challenge may not be initial validation, but the pace of subsequent change. A supplier may issue many releases each year and activate some features automatically. The regulated company needs a process that quickly separates immaterial changes from changes affecting a GxP process. A release-management process should include: Obtain release notes and the planned deployment date. Identify affected functions, interfaces, data and requirements. Assess impact on configuration, risk and documentation. Decide the regression scope and required actions. Execute and approve tests before GxP use where this is possible. Update controlled documents, training materials and traceability. Approve the release or implement an agreed risk-control measure. The supplier agreement should provide enough notice, access to a test environment and clear information about release impact. Where updates cannot be deferred, the customer’s process needs a short assessment window, prioritised regression scenarios and a response plan for an unacceptable result. The validated state also depends on routine operational controls, including access reviews, incident management, CAPA, interface monitoring, periodic evaluation, training, audit-trail review, recovery testing and controlled system retirement. 9. Common SaaS validation mistakes 9.1 Relying only on supplier certificates An ISO 27001 certificate or SOC report may support assessment of security and organisational controls. It does not confirm that the customer’s configuration, workflow, report and user roles meet GxP requirements. 9.2 Reusing an on-premises CSV model without adaptation Repeating documentation and tests designed for locally installed software can create work without addressing the main SaaS risks. The strategy should leverage assessed supplier evidence and focus customer activity on configuration, data, integrations and use. 9.3 Leaving responsibility boundaries unclear An imprecise agreement makes it harder to obtain evidence, investigate incidents and assess releases. Responsibilities should also cover subcontractors, privileged support access, data copies and service termination. 9.4 Testing only the expected path A process may work correctly with ordinary data and fail when an integration breaks, a duplicate appears, an approval is withdrawn or a connection is lost. Negative tests and exception handling are important for critical workflows. 9.5 Treating validation as a one-off event Evidence quickly becomes outdated when subsequent releases are not assessed. The validated-state plan should be designed before go-live, rather than after the first major update. 9.6 Confusing availability with recoverability A high availability percentage does not prove that the company can recover complete records and resume a regulated process within the required time. Backup, retention, recovery objectives, data export and manual continuity procedures require separate assessment. 10. GxP SaaS validation checklist [ ] We have defined the intended use, system boundary and process owner. [ ] We have assessed the effect of each relevant function on patients, products and data integrity. [ ] We have identified the applicable GxP rules and electronic record types. [ ] We have documented data, metadata, interfaces, exports and archive flows. [ ] We have qualified the supplier and assessed its quality system and SDLC. [ ] We have reviewed infrastructure providers, subcontractors and data-processing locations. [ ] We have documented responsibilities in the contract and quality agreement. [ ] We have approved testable user requirements and acceptance criteria. [ ] We have completed a documented risk assessment of functions, data and interfaces. [ ] We have approved the configuration, roles, workflows, retention rules and extensions. [ ] We have verified data migration and interface completeness. [ ] We have tested critical workflows, exceptions, permissions, audit trails and signatures. [ ] We have linked requirements and risks to evidence in a traceability matrix. [ ] We have closed deviations or formally accepted the residual risk. [ ] We have approved the validation report and operational readiness before go-live. [ ] We have a process for release-note assessment, change control and regression testing. [ ] We perform periodic supplier, system, access and validated-state reviews. [ ] We have tested backup, recovery, business continuity and data export. [ ] We have defined archiving, retention and controlled service-exit arrangements. [ ] Personnel have been trained for their roles and responsibilities. 11. How to select a SaaS validation partner A validation partner needs to understand both quality requirements and the technical architecture of the service. Familiarity with CSV templates alone is insufficient for assessing integrations, identity design, cloud controls, automatic releases and supplier evidence. Before engagement, check whether the partner can: translate intended use into GxP scope and a risk-based strategy; assess a SaaS supplier, product documentation and shared responsibilities; prepare the URS, risk assessment, plan, tests, traceability matrix and report; connect quality requirements with security, architecture and data integration; design a sustainable process for maintaining the validated state; support QA, IT and business owners without replacing their regulatory decisions. The delivery model should reflect organisational maturity. One company may need an independent strategy review, another a complete documentation and testing workstream, and a third ongoing support for regular SaaS releases. 12. Why TTMS SaaS validation in pharma requires cooperation between quality assurance, process owners, IT, security and implementation teams. TTMS combines computer system validation capabilities with experience in software development, integration, testing and maintenance for regulated industries. Support can include GxP impact assessment, supplier qualification, validation strategy and documentation, architecture and configuration review, test preparation, data-migration assurance and maintenance of the validated state. The engagement can be adapted to a new implementation, a system already in operation or a programme covering several cloud applications. A practical TTMS engagement may include: Inventory of systems, functions and data flows within GxP scope. Gap assessment of evidence, controls and responsibility boundaries. A risk-prioritised implementation roadmap. Preparation and execution of the agreed validation activities. Support for releases, regression testing and periodic reviews. The objective is to produce evidence that reflects actual system use and can be maintained after go-live. Decisions on GxP scope, risk acceptance and system release remain part of the customer’s quality system. 13. Discussing SaaS validation with TTMS If your organisation is planning a cloud implementation or needs to bring an existing application under control, start with the intended use, supplier evidence and release lifecycle. This establishes the scope before detailed documentation and testing begin. Contact TTMS to discuss a validation strategy, SaaS supplier assessment or support for maintaining the validated state in a GxP environment. FAQ Does every SaaS system used by a pharmaceutical company require validation? No. The scope depends on the intended use of the system and its impact on GxP activities. Applications used solely for general administration may be outside the validation scope. However, systems that create, process, store, or manage critical GxP records require documented assessment and appropriate validation controls to ensure fitness for purpose. Can a SaaS product be certified as GxP compliant? No. There is no universal certification that automatically makes a SaaS product GxP compliant. While suppliers may offer features that support regulatory requirements and provide relevant documentation, compliance ultimately depends on how the regulated company configures, uses, and controls the system within its own processes and quality framework. Is the supplier’s ISO 27001 certificate sufficient? No. An ISO 27001 certificate demonstrates that the supplier has an established information security management system, but it does not verify the customer’s specific configuration, critical workflows, data integrity controls, or GxP compliance requirements. It should be treated as one component of supplier qualification rather than proof of validation. How should automatic SaaS updates be validated? Organizations should establish a process for reviewing release information, evaluating potential impact, classifying changes, and performing risk-based regression testing when required. Critical business processes and GxP workflows should be verified before use whenever possible, or within a controlled and justified post-deployment validation window. Does 21 CFR Part 11 apply to every SaaS system? No. The applicability of 21 CFR Part 11 depends on whether the system creates, maintains, modifies, archives, retrieves, or transmits electronic records required by FDA regulations and whether electronic signatures are used. Each application should be assessed against its intended use and the relevant predicate rules to determine Part 11 requirements.
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