Data & Security

Data handling, confidentiality, and sensible security

QuietOps works with operational data (documents, exports, metrics) to reduce reporting and admin workload. This page explains how we handle client data in plain language. It is not legal advice.

Principles

Data minimisation: we only request the data necessary to deliver the agreed workflow.
Least privilege: access is limited to what is required, and removed when no longer needed.
Separation: client data is kept segregated by engagement where feasible.
Practical controls: we prefer simple, reliable controls over complicated “security theatre.”

Important

We do not claim ISO 27001 or SOC 2 certification. We apply common-sense security practices appropriate to SME engagements and can align to client requirements where reasonable.

What data we typically access

Depending on your workflow, we may work with exports or read-only access from tools you already use (e.g., spreadsheets, CRM exports, accounting summaries, project tools, shared drives). We avoid collecting personal data unless it is necessary for the agreed operational task.

Operational metrics and summaries
Documents required for reporting (SOPs, templates, policy docs, internal guidance)
Structured exports (CSV/XLSX) used for reporting or reconciliation

How we collect data

Preferred: file-based ingestion (you provide exports or drop files into a secure folder).
When appropriate: read-only access via your existing tools (principle of least privilege).
Human-in-the-loop: where accountability matters, we design review/approval steps before outputs are finalised.

AI usage (transparent and bounded)

We use AI to draft summaries, normalise inputs, and generate first-pass narrative for reports and documentation. AI is a tool in the workflow, not a substitute for client accountability.

Review remains human: outputs can be routed for approval where required.
No training on your data: we do not use client data to train our own models.
Tool choice depends on sensitivity: for sensitive workflows, we can use stricter handling approaches (e.g., reduced data, anonymisation, or alternative processing methods).

Plain statement

If you have restrictions on where data can be processed or which tools may be used, we will discuss this upfront and confirm the approach before work begins.

Storage, retention, and deletion

We keep data for the shortest period needed to deliver the engagement and support the workflow. Retention and deletion expectations are agreed per engagement.

Working copies: kept only while actively delivering or supporting the workflow.
Outputs: reports and documentation are delivered to your systems; we avoid being the long-term system of record.
Deletion: upon request (or at engagement end), we delete working copies unless retention is required for legitimate operational reasons agreed in writing.

Access control and credentials

We prefer read-only access where possible.
Credentials are stored securely and access is limited to the minimum required.
Access can be revoked by the client at any time.
Where feasible, we use client-provided service accounts rather than personal accounts.

Confidentiality

We treat client information as confidential by default. We are happy to sign NDAs and comply with reasonable confidentiality clauses. We do not publish client names or details without explicit permission.

Incident handling

If we become aware of a security incident affecting client data within our control, we will notify the client promptly with:

What we know and what we do not know
Immediate containment steps taken
Recommended client actions (e.g., credential rotation)
Follow-up steps and lessons learned

Questions or specific requirements

If you have industry-specific requirements or need a short security questionnaire completed, email us and we will respond quickly.

Contact: [email protected]