Every capability, module by module

CSA360™ is a validation platform for GxP computerised systems, in four modules on one shared record: Estimate the effort, Assess the risk and decide how much to validate, Validate with traceable evidence, and Assure the validated state as systems change.

Computer system validation (CSV) is the documented process of showing that a computerised system used in a GxP-regulated environment does what it is intended to do, consistently. CSA360™ manages that process from the risk decision, through test execution, to a signed conclusion and validation summary report.

Computer software assurance (CSA) is a risk-based approach to assuring software, in which effort is focused where a failure could matter and the reasoning is recorded. CSA360™ records the risk of each intended use, lets your own signed policy set the depth of assurance, and states in writing what is deliberately not tested and why.

The Assess module reads the impact on patient safety, product quality and data integrity, the GAMP software category and any escalation triggers, then applies your organisation's signed policy table. The same inputs always select the same row, and the row, the triggers and the references it cites from the controlled library, including GAMP 5 Second Edition, are shown beside the decision.

CSA360™ is designed for SaaS, on-premises and hybrid GxP computerised systems in pharmaceutical, biotechnology, medical device, and contract research and manufacturing organisations, and for the QA, validation, digital quality and inspection teams who work on them.

Yes. CSA360™ holds the validation record, meaning the decision, the work and the evidence, and produces the controlled documents you file in your eQMS.

AI can draft rationales, test cases and release-note triage using your organisation's own model key. A draft is only a draft: a person approves every one before a signed record can cite it, and citations come only from CSA360's controlled library. Without a key, a built-in template does the drafting.

Signatures are electronic signatures designed around 21 CFR Part 11: the signer signs in again at the moment of signing. The audit trail is append-only and hash-chained, so an altered or removed entry shows, and separation of duties is enforced in the database. 21 CFR Part 11 and EU Annex 11 are both in the controlled library CSA360™ cites from.

Yes. The validation master plan is generated from your workspace's own records, not typed: the purpose and scope, your active signed assurance policy, the validation lifecycle, the system inventory with each system's impact, data integrity criticality, state and last release, the signed validation plans, the review schedules (the next periodic review and access review) and the responsibilities.

Someone who did not generate the master plan signs it, and a signed version never changes. Each new signed version supersedes the last. It downloads as Word in your own template or as PDF, with the signature shown.

Yes. Each system has a signed assessment that states which records and which signatures it holds electronically. For each of 19 controls from 21 CFR Part 11, EU GMP Annex 11 and ALCOA+ data integrity, it states whether the control applies and how it is met, or why it does not apply.

QA, who wrote none of it, signs the assessment. A signed assessment never changes: a revision starts from the signed answers and supersedes it when it is signed. The signed assessment is issued as a numbered, versioned controlled document.

Yes. Supplier questionnaire templates are versioned for your workspace, and a built-in template covers ten topics: quality system, development, testing, change, security, backup, incidents, subcontractors, data integrity and support. The supplier's answers, or the outcome of a supplier audit, are recorded on the vendor assessment.

The audit outcome records the date, the auditor, the findings by severity (critical, major and minor), the verdict and where the report is kept. The assessment's signature seals the audit outcome, or the supplier's answers, and a signed assessment never changes.

A validation project is the validation work for one event on one system: an initial validation, a change or a revalidation. It groups the plans written for that event, and its stage, planning, in execution, concluded, closed or cancelled, follows from the work.

Yes. Requirements carry a type: user, functional or design. The user requirements specification (URS), functional specification and design specification are generated from the signed requirement baseline as numbered, versioned controlled documents, each listing the baselined requirements of its type with their risk and data integrity control, and each approved by the baseline's own signature.

Each system has a register of configuration items: the setting, the value it must have and the rationale. Items are edited and retired, never deleted. QA signs a configuration baseline in one step, a frozen copy of the active items, and the signer cannot be someone who edited any of them. The register shows what changed since the baseline was signed, with old and new values, and the configuration specification is issued from the signed baseline.

Each requirement can be rated for severity, likelihood and detectability. Severity and likelihood give a risk class, and the class with detectability gives the GAMP 5 priority, so the risk follows from the ratings and the database enforces it.

The priority decides the test rigour: a high priority needs a scripted test, a medium priority a scripted or exploratory test, and a low priority an exploratory test or accepted supplier evidence. The traceability matrix shows each requirement's ratings, risk class and required rigour, and whether its covering tests meet it.

Yes. Starter libraries cover Veeva Vault QualityDocs, SAP S/4HANA Cloud, Salesforce Service Cloud, Microsoft 365 (SharePoint) and ServiceNow ITSM. Each holds requirements with their risk, configuration items and scripted tests to adapt, and was reviewed by a validation professional.

A system picks the closest library by vendor or name and loads it. The requirements, configuration items and tests arrive in the system for you to adapt, and anything the system already has is left as it is, so nothing you adapted is overwritten. Tests arrive as drafts, and nothing is approved by loading.

Yes. A validation plan starts from the signed strategy. A live traceability matrix links each requirement to its risk, test, result and evidence, with gaps named, and exports as Excel and PDF. A signed conclusion and a validation summary report, with a deviation summary and the open items, close the record.

Tests run step by step, expected against actual, with a witness where needed. Evidence files and screen captures are stored with a hash, and someone other than the performer reviews the result. Automated results can be imported from JUnit XML or CSV files, labelled as imported and attested by a person.

Yes. A person claims a piece of the supplier's test evidence for specific requirements, naming the supplier document and section, the product version it was produced on and why it applies to your intended use. A different reviewer accepts or rejects the claim, and accepted evidence shows beside the requirement in the traceability matrix, the signed conclusion and the validation summary report, labelled as the supplier's.

Yes. A protocol is one stage of testing under a validation plan, IQ, OQ, PQ or your own stage name, with its objective, prerequisites, acceptance criteria and the approved test cases it runs. QA signs it before execution and its tests cannot run until then, and QA signs again once every run is reviewed and every incident is dispositioned, with a written assessment against the acceptance criteria. Authors and executors cannot approve. The protocol and its protocol report are issued as numbered, versioned controlled documents.

Yes. Only runs started after a protocol is approved for execution count towards it, so a later protocol can run the same approved test cases again after a change.

Every test incident becomes a numbered validation deviation. It is closed with a recorded investigation: a classification as a script error, execution error, system defect, configuration, environment, specification error or other, the root cause, the impact on validation and the resolution, with an optional CAPA reference to your eQMS. The database refuses a closure without the investigation.

Yes. Each protocol has a deviation log listing the deviations raised on its runs, with the test, severity, classification, root cause, impact, resolution and the retest outcome. The project page lists them across its protocols, and the log is issued as a controlled document that a second person approves.

Yes. The workspace has a test library of scripted tests and exploratory charters. Any test can be saved to the library, and a new test on any system can start from a library template, with the test form pre-filled.

Nothing. Editing a template creates its next version, and a test already written never changes. A test started from the library is an ordinary draft that someone other than the author approves, and it records the template and version it came from.

Yes. A GxP spreadsheet is a validated item with its own spreadsheet validation for each workbook version. The version is identified by its file hash, formulas are checked against independently worked results, and the protection checklist is completed: locked cells, sheet and workbook protection, input validation, macros, controlled storage, versioning and change control. A downloadable Excel worksheet is included.

Someone who did not perform the validation signs it, and only when every check passes. A signed validation never changes, the next version of the workbook is the next validation, and it is issued as a controlled document.

Yes. QA signs a release certificate that freezes the latest signed conclusion, the intended uses and every current controlled document with its approval and any external approvals. It is refused while any deviation on the system is open, and it is issued as a controlled document.

Yes. One export gives every current controlled document as HTML and Word, in your template where one is set, with a manifest of each document's number, version, status, approvals, external approvals and hashes, and the release certificates. Client approvals made outside CSA360, in wet ink or the client's own e-signature, are recorded against each document and listed in the package.

Yes. Each system has a register of issued deliverables, such as the risk assessment, ERES and data integrity assessment, strategy, validation plan, user, functional, design and configuration specifications, test protocols, protocol reports and deviation logs, traceability matrix and validation summary report, numbered, versioned and frozen. Word downloads go into a template you upload, with your styles, headers, footers and images, and a changed source issues the next version under the same number.

A change is recorded by hand, through the inbound API, or from RSS, Atom and Statuspage feeds. Release notes are triaged item by item against your intended uses and requirements. A person confirms the impact and classifies earlier evidence as retained, partly applicable, superseded, invalidated or review required, with a written reason, and a signed reassessment can start a targeted revalidation that reopens only the affected requirements.

A release pack is one controlled document of how a vendor release was handled: the change and its triaged items, the impact assessment, the signed reassessment, the targeted revalidation, the results for the affected requirements, the newest signed conclusion and the supplier's own files. A manifest and checksums let the receiver check it, and readiness checks say whether it is ready.

Yes. Once the impact is confirmed and the reassessment decision signed, QA approves the change for implementation by e-signature, stating the planned change and, where your eQMS owns change control, its reference there. The implementer records what was done, and someone who did not implement it verifies and closes the change with a second signature.

Closure is refused while the configuration register differs from its signed baseline, so the new baseline is signed first, and, when the decision required reassessment, until the validation project opened for the change is closed.

Yes. Every change shows a release timeline from vendor publication through impact, decision, approval, revalidation, implementation and closure to the release-for-use certificate. It ends with the days elapsed, from publication to back in production.

Each step is the timestamp of the record that made it, such as the impact assessment, the signed decision, the change approval, the revalidation project and the release certificate, so you see how long each vendor release took from its own records.

Yes. Each validated system has a periodic, signed access review. The reviewer lists every account reviewed with its role and a decision to keep, change or remove it, and records the findings and the date the next review is due.

Someone who did not perform the review signs it, and a signed review never changes. The latest signed review sets the next due date, which the system shows as due or overdue, and the next review starts from the accounts kept. A signed review is issued as a controlled document.

Yes. Each system can have a signed record per backup and restore test: the date, what was backed up, how the restore was done and checked, the result, the observations and where the evidence is kept. The record references the evidence, such as a ticket or a share location.

The performer records the test and can correct the draft. Someone who did not perform it signs it, a signed record never changes, and it is issued as a controlled document.

Yes. A data migration project carries a migration record with the plan (source, target, data in scope, approach and acceptance criteria) and the field mapping. Someone who wrote neither approves them before the migration, and the plan is issued as a controlled document.

After the migration, the verification is recorded for each data object with record counts and sampled checks. A person who did not write the report approves it, the approval is refused while any mismatch is unexplained, and the report is issued as a controlled document.

Yes. A retirement project carries a retirement record with the plan: why the system is retiring, what happens to its data, the retention period and basis, how retained records are read afterwards and the decommissioning steps. Someone who did not write the plan approves it before decommissioning, and the plan is issued as a controlled document.

The retirement record holds the archive and retention check, which records where and how the data is archived and the result of a retrieval test, with the decommissioning date and the conclusion. A person who did not write the report approves it only once retrieval has passed, the approval marks the system retired in the inventory, and the report is issued as a controlled document.

Each system can have a sealed, signed inspection narrative, and so can the portfolio, and either can be reconstructed as of a past date. Your QA team shares released records in an inspection room, logs the inspector's requests, and can download an inspection pack.

Changes come in from your ITSM, a vendor feed or your eQMS through an open, documented change connector contract. Each change is identified by its source and your own reference, so your system can find it again.

Yes. Your system can ask CSA360™ for the impact assessment, the revalidation decision and the change-control status of any change it sent, including the approval, the implementation, the verification and the closure.

Yes. Each QMSdesk workspace connects its own CSA360 workspace. A change control sent from QMSdesk shows its validation consequence on the QMSdesk change: the impact, the revalidation decision and the change-control status.

The QMSdesk change number is its reference in CSA360™, so a change sent again is the same change. CSA360™ records the impact, the revalidation decision and the change control, and the QMSdesk change reads and shows them on request. A workspace can also have CSA360™ send signed webhook events to endpoints of its choice.

Yes. CSA360™ sends signed webhooks to your own systems, such as your eQMS, ALM or ITSM. A workspace administrator adds an HTTPS endpoint and chooses the events: changes received, impact confirmed, decisions and records signed, change-control steps, test runs completed and reviewed, and inspection narratives released.

Yes. The integration API is published as an OpenAPI 3.1 specification covering the change endpoints, the release-notes feed and how to verify a webhook event. Each event is signed with HMAC-SHA256, so the receiver can verify it came from CSA360™.

Yes. A documented API answers whether a system is validated for a use, from signed records only. For each intended use it returns validated, validated with conditions, change pending, not validated or retired.

It is read-only and answers only for your own workspace, using your workspace's integration key. Every question is recorded in the audit trail with the answer that was given.

Yes. A workspace administrator downloads the whole workspace as one file: every record, the full audit trail, every signature and every evidence file. The archive is available after a licence ends.

The archive includes a checker that verifies it is complete and unaltered on your own computer, with nothing of ours running. It re-checks the file hashes, the audit trail chains and the signature links.

Yes. For each release, a validation package for your auditor is generated from our test evidence: intended use and scope, risk assessment, test evidence, a matrix of 21 CFR Part 11 and EU Annex 11 controls, release notes and a change notice.

It is generated from the automated test run of the release itself. Each CSA360 requirement is traced to the test that carries it, with its result in that run, and each control in the matrix cites the tests that prove it or says where a procedure covers it.

Yes. A consultancy runs each client in its own workspace and switches between them from one sign-in, with the second factor asked on each move. It can copy its questionnaire and test templates into a client's workspace.

The client signs a handover package: every system's full validation package with a manifest of each current document and its hash. On handover the firm's access to the client's workspace ends, and the client's own people keep theirs.

Yes. From the reviewed actual hours of your approved estimates, CSA360™ proposes better unit effort for the estimating method. A person accepts the proposals into a new method version, and someone else signs it into use, so a person approves every change.

For each work package, the proposal shows the median observed effort per unit as most likely, with the lowest and highest observed as the range, against the method's current rate. A person accepts some or all of it into the next draft version, whose accepted rates name the estimates they came from, and a second person signs the version into use.