Cloud & hosting audits
Audit hosted services against the regulated process they support, including shared responsibility, subprocessors, and change practice.
Technology, cloud & systems audits
Audit the system as it runs, not as it was documented.
Regulated work runs on services nobody in the organization operates: managed platforms, hosted data stores, third-party interfaces, and product features that change on the supplier’s release schedule.
Perspective
The question is not whether a system was validated, but whether the operating reality behind it can be relied upon — how data moves, where it is transformed, which controls belong to the supplier, which quietly remained yours, and what happens on the day the interface silently starts dropping records. Answering that requires reading configuration and logs, not just procedures.
Capabilities
Specialist support, connected to the whole system.
Scope is tailored to the engagement; these are the core areas in which QA4Tech can contribute.
GxP system audits
Examine validation state, configuration, access, audit trails, and whether the system in use still matches the one that was validated.
Data flow & integrity audits
Trace data from origin to reported result through every transformation, interface, and manual intervention along the way.
Interface & integration audits
Examine the places systems meet — reconciliations, error handling, and the silent failures that live between two owners.
Technology service audits
Assess development, support, hosting, and managed-service providers on the practices that actually bear on your regulated activity.
Provider readiness
Help technology providers understand, evidence, and withstand the assurance expectations of regulated customers.
Audit scope
Five technology subjects, each audited differently.
Scope is defined by the regulated process and the risk it carries, not by a fixed technology list. These are the layers the work most often reaches, and each rewards a different kind of attention.
Infrastructure & cloud
Hosting, compute, storage, network, backup and recovery, and the shared-responsibility boundary between provider and tenant.
GxP computerized systems
eClinical, laboratory, manufacturing, and quality systems: validation state, configuration control, access, and audit trail adequacy.
Data platforms & pipelines
Warehouses, lakes, transformations, and reporting layers, where the original meaning of a value is most often lost.
Interfaces & integrations
APIs, middleware, and file transfers between organizations, including reconciliation and what happens to a failed record.
Technology services
Software development, release, environment management, support, and managed operations performed by people you do not employ.
Where failures hide
Audits concentrate at the boundaries.
Failures rarely occur in the middle of a well-understood system. They occur at boundaries — of ownership, of data, of change, and of attention.
- The ownership boundary: controls both sides assume the other is operating
- The data boundary: every point where data is transformed, mapped, or re-keyed
- The change boundary: how supplier releases reach production, and what notice you get
- The attention boundary: alerts and exception reports that exist but nobody reads
- Environments: whether test, staging, and production genuinely differ as claimed
- Access: privileged accounts, shared credentials, and leavers who still have both
- The exports, spreadsheets, and manual steps missing from the architecture diagram
How it is commissioned
The same subject, three kinds of engagement.
Technology audits run under any of the audit types. The subject sets what is examined; the type sets the access, the preparation time, and what the report has to support.
Auditing your own environments, systems, and change practice, often as part of a self-inspection programme.
Auditing a software, cloud, hosting, or managed-service provider before qualification or on a risk-based cycle.
After an outage, a data loss, an integrity signal, or a migration that did not go as planned.
Approach
Context first. Evidence throughout.
A clear sequence keeps the work rigorous while avoiding unnecessary process.
- 01
Anchor on the process
Establish the regulated activity, the decisions it produces, and the data that has to be trustworthy for those decisions to hold.
- 02
Follow the data
Trace the real path end to end, including the steps nobody documented, using live demonstration rather than description.
- 03
Separate the controls
Determine which controls the supplier operates, which are yours, and which are assumed by both and operated by neither.
- 04
Report what is material
Set out the exposures that matter, the evidence behind them, and a proportionate route to closing them.
Deliverables
What you receive.
A technical audit record that a quality unit can act on and an engineering team cannot dismiss.
- An audit plan with scope, risk rationale, and a structured evidence request
- A written report with graded findings and the basis for each conclusion
- A data-flow or shared-responsibility view where the engagement produced one
- An explicit conclusion on suitability, with conditions where relevant
- Review and challenge of the response and corrective action plan
- Formal closure documentation once actions are verified as effective
Reference frameworks
The expectations applied to the technology.
Regulatory expectation and technical control frameworks are used together, so a finding lands with both the quality unit and the engineering team.
- EU Annex 11 & 21 CFR Part 11
- Electronic records, audit trails, access control, and the operational controls expected around a regulated system.
- EMA guideline on computerised systems and electronic data in clinical trials
- European expectations for computerised systems, cloud services, and service providers used in trials.
- ALCOA++ data integrity principles
- Applied to real data flows rather than to a system in isolation, including transfers between organizations.
- GAMP 5 (2nd edition)
- Risk-based scaling of audit effort across infrastructure, platforms, and configurable services.
- ISO/IEC 27001 & SOC 2
- Used as supplier evidence, with certificate scope, report period, and complementary controls examined rather than accepted.
These are examples, not a complete list. The frameworks and criteria that apply to a particular engagement are identified and agreed as part of defining its scope.
Typical applications
Where this work can apply.
- Cloud or SaaS platforms supporting a regulated process
- Data-integrity audits across connected systems
- Auditing a software, hosting, or managed-service provider
- Interface and integration risk after a platform change
- Technical due diligence before contracting a provider
- Providers preparing for regulated-customer scrutiny
Start a conversation
Bring the right level of assurance to the next decision.
Begin with a focused discussion about context, risk, evidence, and the outcome you need.