# Ketryx Quality Practices **How we build, validate, and govern the Ketryx Platform under a certified quality system.** - **Source:** https://www.ketryx.com/assets/ketryx-quality-guide - **Type:** White Paper - **Built on:** ISO 13485 · IEC 62304 · ISO 14971 · ISO 27001 · SOC 2 Type II --- ## Quality at Ketryx Ketryx builds software that regulated companies use to develop and release their own products. That places quality at the center of everything we do. Our customers in medical devices, diagnostics, pharma, and digital health are held to demanding standards, and the platform they rely on has to meet the same bar. So we hold ourselves to it. The Ketryx Platform is built and maintained under a quality management system that aligns with the same standards our customers follow, including ISO 13485, IEC 62304, and ISO 14971. The platform governs its own development, which means the controls described here are the controls we run our own engineering and quality work through every day. This document explains how our quality system works, what we are certified against, how we validate the platform, and the practices behind risk, change control, supplier qualification, audits, and records. It is written for the people who evaluate us: quality engineers, regulatory affairs leads, and IT auditors who need evidence. Our quality system is built on a simple company mission: making software safe and reliable. Everything else follows from that. We manage a risk-based Total Product Lifecycle process, which means quality is not a gate at the end of development. It is present from the first requirement through release, maintenance, and eventual retirement of a version. At the core of the system is risk-focused change control. Before any change moves forward, it is assessed for the risk it could introduce, in line with ISO 14971, and that assessment is what decides how much process the change needs. Design and development, configuration management, release, and maintenance all run through that same controlled path. When a problem turns out to be systemic, a Corrective and Preventive Action process takes over to fix the root cause and keep the same issue from coming back. > **Figure 1.** The Ketryx quality system, with risk-focused change control at its core. Risk runs through every controlled change across the lifecycle: Design & development, Configuration management, Release & deployment, and Audit, CAPA & maintenance all connect to a central **Risk-focused change control**. Built on ISO 13485 · IEC 62304 · ISO 14971 · ISO 27001 · SOC 2 Type II. What makes our approach unusual is that we use the product on ourselves. The Ketryx Platform is the system of record for its own lifecycle. Our requirements, risks, tests, change records, and approvals live in the platform, under the same quality management system our customers are subject to. When we tell you a control exists, we mean it is the control we operate under, not a policy written for an audit binder. ## Quality management system Our quality management system is documented in a top-level Quality Manual that sets the scope of the system, references the standards and regulations we follow, and describes how each procedure interacts with the others. Underneath it sits a controlled set of policies, plans, and standard operating procedures covering document control, records, training, purchasing, internal audit, change management, risk management, and the software lifecycle. The system is reviewed by management on an annual basis to confirm it is effective and current. We maintain independent, third-party verification across both the quality and security sides of the business. The Ketryx Platform is certified by UL to ISO 13485:2016 for the quality management system, to IEC 62304 for software lifecycle processes, and to ISO 14971 for risk management. On the information security side, Sensiba certifies our Information Security Management System to ISO 27001:2022 and issues our SOC 2 Type II report. Certificates for all of these standards are available at trust.ketryx.com and can be filed directly in your validated-tools or supplier records. > **Figure 2.** Independent certifications and attestations (all certifications available at trust.ketryx.com): > - **ISO 13485:2016** — Medical device QMS — Certified by UL > - **IEC 62304** — Software lifecycle — Certified by UL > - **ISO 14971** — Risk management — Certified by UL > - **ISO 27001:2022** — Information security — Certified by Sensiba > - **SOC 2 Type II** — Trust services — Audited by Sensiba These certifications matter because they give you independent assurance. A notified body and external auditors have reviewed and approved how we build, test, maintain, and secure the platform. That review is not a one-time event. It is renewed annually, and the evidence behind it is version-controlled inside the platform so it can be produced when you or your auditors ask for it. ## Risk management Risk runs through the whole system rather than sitting in a separate binder. Our risk management process conforms to ISO 14971, the international standard for applying risk management to medical devices, and it is applied company-wide across the product lifecycle in step with our Application Lifecycle Management Plan. We work at two levels. Item-level risk attaches to individual configuration items, while global-level risk covers the broader product and the processes that produce it. The process follows the familiar arc: we analyze risk, evaluate it, apply and verify risk controls, and then evaluate the residual risk that remains. Criticality is judged against a defined set of core risk considerations documented in our Risk Management Policy, so the assessment is consistent from one reviewer to the next. High-criticality anomalies are formally risk assessed, and both the initial and the residual risk have to reach an acceptable level before a change moves forward. Monitoring does not stop at release. Production and post-release experience feed back into the analysis, which is what keeps the risk picture current. > **Figure 3.** The ISO 14971 risk management process applied across the lifecycle. Applied at item level and global level: Risk analysis → Risk evaluation → Risk control → Residual risk evaluation → Acceptable risk? (judged against core risk considerations), with Production & post-release monitoring feeding back into risk analysis. Risks are recorded as configuration items and traced to the anomalies and changes that affect them. Risks are not free-floating. Each one is recorded as a configuration item in the platform and traced to the anomalies and changes that affect it, so the link between a hazard, the controls that address it, and the code that implements those controls is always visible. Information security risk is handled on the same principle through our ISO 27001 ISMS, assessed for its effect on the confidentiality, integrity, and availability of information and captured in a documented risk assessment report. ## Validation and qualification practices Validation is a fact of life in regulated work. You have to show that the tools and systems you depend on do what they claim to do. We wrote about our approach in detail in the post *How to Validate Ketryx*, and the short version is this: we validate the platform continuously, and we ship the evidence with every release so you do not have to build it from scratch. The Ketryx Platform is classified as a Tier 2 support tool under IEC 61508-3, meaning it supports verification and validation activities without itself generating executable code that ships in a customer's safety-related system. We validate each new version by building the next version inside a version that has already been validated. If the verification and validation activities for the new version pass, the version used to build it is qualified. In practice, every production release serves as validation evidence for the version that produced it, so validation happens on each release cycle rather than on a calendar. Qualification of a new version is reviewed and approved by our R&D and Quality leads before it is used for formal work, and any use of a non-qualified version is logged as an anomaly and corrected. > **Figure 4.** Each release validates the prior version, and ships with a customer validation package. Version N (validated & qualified) → each release validates the prior → Version N+1 (built & verified). **Customer validation package:** Approved test plan and test results; Requirements traceability matrix; Generated release documentation; Immutable, time-stamped audit trails; ISO 13485 / IEC 62304 / ISO 14971 certificates. Independently reviewed by Quality, version-controlled, auditor-ready. For customers, this maps cleanly onto the installation, operational, and performance qualification model you already use, and onto Computer Software Assurance thinking. With every major and minor release we generate a customer-shareable validation package: version-controlled, independently reviewed by Quality, and preserved with immutable audit trails. Most customers either accept that package as supplier documentation or add a light layer of their own use-case testing on top of it. For electronic records and signatures, we apply the principles of 21 CFR Part 11 to our release and quality records. Approvals are captured with validated electronic-signature functionality that records the signer, the timestamp, and the meaning of the signature, backed by time-stamped audit trails. ## Quality system practices The sections below give a high-level view of the procedures that keep the system running day to day. Each is governed by a controlled standard operating procedure or plan, and each produces records that an auditor can inspect. ### Change control and configuration management Every change to the platform or to the quality system moves through a controlled process defined in our Change Management Plan, which aligns with IEC 62304 and ISO 13485. We work at two levels. Item-level changes are direct, small-scope edits to existing configuration items, and they are automatically required to be approved and placed under control before any version containing them is released. Global-level changes, the kind driven by problem correction or larger product work, require a controlling change record that describes the change and traces to everything it affects or creates. A change record can be documented as a pull request or a change request item in Ketryx. Either way, the owner and reviewers assess the change for risk against our Risk Management Plan and core risk considerations, and their approval signature means that assessment has been done. Following this risk-based approach, non-substantive changes, such as cosmetic edits or logging that does not touch requirements or risk controls, are marked as such and follow a lighter path, while anything that touches safety or data-related behavior requires additional risk mitigation and controls. Configuration management runs on the same backbone: anomalies, complaints, CAPAs, and change records are all managed as configuration items, with traceability between requirements, risks, code, tests, and the changes that touch them. ### Supplier and vendor qualification We only use qualified and approved suppliers for GxP products and services, and our Quality Assurance team evaluates, qualifies, and approves a supplier before it is used. A supplier falls into scope for evaluation when its product or service could affect the safety, performance, or regulatory compliance of what we deliver, or when we could not serve customers without it. Suppliers with no such impact are treated as non-critical. Approved suppliers are recorded on a Qualified Supplier List maintained inside the platform. Evaluation looks at quality, timeliness, and cooperation, and assigns a risk level that determines whether ongoing surveillance is needed. We re-evaluate suppliers periodically, generally at least once per year, timed to coincide with our annual management review, with more frequent checks where the risk or the supplier's history calls for it. Where added assurance is warranted, we request current certifications, put a Supplier Quality Agreement in place, or conduct a supplier audit. Open-source dependencies, or software of unknown provenance, are handled through a separate supply-chain management process rather than this one. ### Audit readiness and third-party audits We are audited by external parties on a recurring basis. UL, as a notified body, audits our quality management system against ISO 13485, IEC 62304 and ISO 14971. Our information security program is independently audited by Sensiba for ISO 27001:2022 and SOC 2 Type II. These are third-party reviews, renewed on each standard's annual cycle, not internal claims. Audit readiness is a byproduct of how the system runs day to day, not a scramble before an auditor arrives. Records are uniquely identified, retained, and retrievable, and electronic records carry time-stamped audit trails covering creation, modification, and deletion. Electronic signatures on quality and release documents give an inspector a clear, attributable record of who approved what and when. Because the evidence is generated and stored as work happens, we can produce it on request rather than reconstruct it. ### Incident and nonconformance management We separate feedback into three categories aligned with IEC 62304 and ISO 13485: anomalies, complaints, and change requests. An anomaly is any condition that deviates from what is expected based on requirements, specifications, or standards. A complaint alleges a deficiency in the identity, quality, reliability, usability, safety, or performance of our software. A change request is a documented specification for a change. External feedback can be raised through the platform or sent to our feedback channel, and we acknowledge it within the same or the following work day. Anomalies are assessed for criticality against our core risk considerations. Where the root cause is not obvious, we use structured analysis such as the five-why technique, and high-criticality anomalies are formally risk assessed. The outcome determines the response. An anomaly tied to an unacceptable risk enters correction and is fixed in the next planned or patch release, while low-criticality items can be deferred based on capacity and prioritization. When a problem points to something systemic, affects multiple releases or customers, or needs more than a code fix, we open a Corrective and Preventive Action to address the root cause and prevent recurrence. ### Training and competency Personnel who perform work governed by the quality system or the software lifecycle are trained and shown to be competent before they execute that work. The Ketryx Platform serves as our learning management system, so training assignments, completion, and records live in the same place as the rest of our quality data. Personnel also complete training in our security compliance tooling to meet SOC 2 requirements. Training is tied to job role through defined groups, and completion is acknowledged with a Part 11 electronic signature confirming the person has read and understood the document. When a controlled document is revised in a way that introduces new requirements, affected personnel retrain on the new effective version before performing any task it governs, typically with a two-week training window before the revision takes effect. Training records are retained for the full duration of a person's employment. ### Document control All quality system documents are controlled under our Document Control procedure, which applies the relevant requirements of ISO 13485, ISO 14971, and IEC 62304. Documents are reviewed and approved before they are issued, named and labeled to a consistent scheme, and assigned a security level that governs who can access them. We also control the external standards we depend on, so the versions of ISO 13485, ISO 14971, and IEC 62304 in use are managed inside the platform. Controlled documents are reviewed at least once a year to keep them clear, accurate, and aligned with current standards, with revisions handled through the same review-and-approval path and retraining where needed. Obsolete versions are archived and access-restricted so they cannot be used by mistake. All documents are backed up daily through AWS backup jobs and stored across multiple regions with long-term retention. ### Records management Records are the evidence that the quality system is working, so we manage their identification, storage, security, retrieval, retention, and disposition deliberately. The default retention period for records under the quality system is 15 years from the effective date. Version-release documents are kept for at least two years from release, and for at least the defined lifetime of the software version. Where more than one retention rule could apply, the longest one wins, and any legal or audit hold extends retention until the hold is lifted. Electronic records carry time-stamped audit trails that capture the creation, modification, or deletion of a record and the user responsible, with justification captured for changes and deletions. Access follows role, defaulting to view-only unless a person's role requires more, and credentials are never shared. Records are backed up and archived through AWS to protect against catastrophic loss, and when a retention period expires with no hold in place, records are disposed of using methods that guarantee the data cannot be recovered. ### Internal audit We run internal audits on a yearly schedule to confirm the quality system is implemented and effective. On a two-year cycle, the audit covers the full set of clauses across ISO 13485, ISO 14971, and IEC 62304, and the report for that audit includes a checklist confirming clause coverage. In the intermediate years, the scope can be reduced based on a documented assessment made during audit planning. If an audit has to be delayed, the delay is approved by the Management Representative and documented with a justification. Auditors are selected for their knowledge of our processes, the relevant standards, and audit practice, and they are never allowed to audit their own work. We can bring in external auditors as well, and we keep their credentials on file. Findings are documented in the audit report, and where a finding warrants it, a CAPA is opened and tracked to closure by the manager responsible for the audited area. The audit report is compiled within 15 business days of completion, and corrective action can begin before the final report is issued. ### Management review Top management reviews the quality system at planned intervals, at least once a year, to confirm it remains suitable, adequate, and effective. The review is the point where the separate threads of the system come together and leadership decides what to change. It is owned at the top, not delegated to whoever ran the last audit. > **Figure 5.** Inputs to and outputs from the annual management review. > **Inputs:** Internal & external audit results; Feedback and data analysis; Supplier performance; CAPA status; New / revised regulations; Actions from prior reviews. > **Outputs:** QMS & product improvements; Resource decisions; Regulatory response actions; New / updated CAPAs. Inputs include internal and external audit results, the analysis of feedback and monitoring data (complaints, anomalies, change requests, and product and process trends), supplier performance and re-evaluations, CAPA status, new or revised regulatory requirements, and the status of actions from previous reviews. Supplier re-evaluation is timed to coincide with the review so the two reinforce each other. The outputs are decisions and actions: improvements to the quality system and the product, resource decisions, responses to new or changed regulations, and CAPAs where a gap needs formal correction. Everything is documented and tracked to closure, which keeps the system improving rather than just holding steady. ### Software development lifecycle Our software development lifecycle is defined in our Application Lifecycle Management Plan, which covers every stage from concept to retirement and is built to meet IEC 62304 and IEC 61508-3. The same plan is what qualifies the Ketryx Platform as a Tier 2 tool. Development moves through a defined succession of environments. Demo, Canary, and Dev are internal spaces for experimentation and informal testing and are never used for controlled work. Staging is where a release candidate goes through formal verification and validation against an approved test plan. Internal is where the platform governs its own quality processes, and Production is the environment our customers use. > **Figure 6.** The controlled release pipeline, from internal sandboxes to production. Demo / Canary / Dev (internal sandbox, no controlled work) → Staging (formal V&V vs. approved test plan) → Internal (governs Ketryx's own QMS) → Production (customer environment). **Dual independent sign-off:** one R&D Lead and one QM Lead approve every production release. Releases are controlled under our Deployment and Release procedure. Before a production release, all configuration items in the release are reviewed and approved, anomalies are addressed or formally deferred, the traceability matrix is checked so that every design output and validation test connects back to a requirement, and all release documents are generated and confirmed current. The release itself is approved by one R&D lead and one Quality lead acting as independent signers. For urgent situations, a controlled hotfix path lets us respond to a high-criticality issue or a business-critical need while keeping a contemporaneous record of the evidence, analysis, and decisions, followed by a standard release to formalize the change. Underpinning all of this, our code is written to documented coding standards enforced through compiler configuration, automated static analysis, mandatory peer review, and developer training. Integrations with the tools in our development chain, including Jira and GitHub, are verified for compatibility so that data moving between systems keeps its integrity and does not introduce errors into the work the platform is used to produce.