Independence-by-Design: Why 'Read-Only' Should Be an Architecture, Not a Policy

Auditor independence is one of the two or three properties that make attestation a defensible category. The AICPA Code of Professional Conduct requires it. The AT-C attestation standards require it. State board licensing regulations enforce it. And yet the software layer of the audit-firm practice — the tool that carries the working papers, the evidence, the client communication, and the final report — is where independence is most often treated as a matter of policy rather than architecture. That is the vulnerability that is going to produce the first material peer review finding on a bundled auditor-and-platform vendor, and it is the reason a serious cyber-attest practice should look at "independence-by-design" as a hard architectural constraint on the tool, not as a checkbox on the vendor's compliance page.

This is the case for architectural independence in audit-firm software — what it means, what it excludes, and how to evaluate a platform's real answer to the independence question rather than the marketing-shaped one.

What independence requires, briefly

The auditor of an attestation engagement must be independent both in fact — actually free of relationships or interests that would compromise objectivity — and in appearance, meaning a reasonable, informed third party would not conclude that the auditor's objectivity is impaired. The rules apply to individual practitioners, to firms, and to network affiliates. The independence question is not just "is the practitioner objective?" — it is "would a reasonable outside observer, reviewing the entire engagement including the tooling and the non-audit-service relationship, conclude the practitioner's objectivity is unimpaired?"

The specific rule that governs the software boundary is AICPA ET 1.295 — Non-Attest Services. The practitioner may not perform activities that would be the responsibility of management on the attest client. Management-responsibility activities include designing the control, operating the control, remediating a deficiency, or maintaining the underlying records the control produces. Software that performs any of these on behalf of the auditee, in a workflow the auditor also uses, creates a boundary problem.

Why policy independence is a peer-review vulnerability

Every platform vendor that touches attestation work asserts independence at the policy layer. "The auditor's activities are logically separated from the client's activities." "Access controls prevent the auditor's team from writing to the client's compliance state." "We are SOC 2 certified." These are policy statements — they describe what the vendor intends, controls for, and audits itself against. They do not describe what the platform architecturally cannot do.

The distinction matters for two reasons. First, policy controls can fail — an access control misconfiguration, a support engineer's break-glass permission, a code deployment that removes a boundary check. When they fail, independence is compromised on the specific incident, and the compromise is retroactive to any engagement affected. Second, in the appearance analysis, a peer reviewer or state board inspector asks not "did the policy work in every case?" but "could a reasonable third party, understanding the platform's capabilities, conclude the auditor's objectivity was unimpaired?" A platform that can write to the auditee's posture — even if policy says it doesn't — sits in a weaker appearance position than a platform that architecturally cannot.

What "architectural independence" means

Architectural independence is a specific, technical property of the platform: the write paths that would compromise auditor independence do not exist in the software. Not "are disabled by policy." Not "require additional authorization." Not "are audited via logs." They are absent from the codebase. The platform's design is such that even a malicious platform operator, given full physical access to the deployment, could not use the platform to modify the auditee's compliance state on the auditor's behalf.

• Read-only integrations with the auditee's environment.: The platform pulls evidence via read-only API credentials, read-only IAM roles, or one-way file uploads from the auditee. It does not carry write scopes to the auditee's cloud, IAM, IdP, or compliance-automation tooling. If the underlying integration protocol requires a write scope for other reasons, the platform must not use it — the credential must be scoped read-only or the integration must be architected around the constraint.
• One-way evidence flow from the auditee.: Evidence uploaded by the auditee lands in a workpaper the auditor accesses. It does not flow back to the auditee's compliance state. If the auditor notes an exception, the note lives in the auditor's workpaper — the client sees the note through a report or a communication channel, not through a change to the client's own compliance record. Bidirectional workflow creates independence exposure.
• No auditor-side ability to remediate.: The platform does not offer a "remediate this exception" or "fix this control" workflow that the auditor can invoke on the client's behalf. Remediation is a management activity; auditors do not perform management activities on attestation clients. Software that offers such a workflow — even if the auditor is trained not to use it — is a policy-independent platform, not an architecturally-independent one.
• No shared operational infrastructure between auditor and auditee tenancies.: The auditor's workpaper store and the auditee's compliance state, if both exist on the platform, are architecturally separated tenants with independent access controls, independent backups, and no shared support-side elevation. A support engineer with root over one must not be able to reach the other. Where the two tenants are functionally coupled (e.g., evidence flows from auditee tenant to auditor tenant), the coupling is a one-way controlled interface, not a shared store.
• Cryptographic integrity guarantees on evidence and working papers.: Evidence captured during the engagement is hash-committed at capture time and timestamp-anchored to an external source. Working papers are hashed and signed at signoff. If the platform vendor is later compromised or is subject to a subpoena or investigation, the integrity of the engagement's evidence and workpapers is provable independently of the platform vendor's own attestation of its access-log integrity.

The three shapes of audit-firm platform and how each resolves the independence question

The market has evolved into three distinct shapes of platform for cyber-attest work. Each shape sits in a different position on the independence question, and the shape is often the most important variable in the buyer's evaluation.

The choice among these three shapes is not a "which is better" question; each fits a different practice model. The choice is a "which fits my practice's positioning" question. A practice that differentiates on independence and audit quality cannot use the bundled shape without giving up its differentiation. A practice that wants to enter the market fast with commoditized volume may prefer the bundled shape's operational efficiency and accept the appearance-independence tradeoff. A practice that already has a robust client base and a peer-review posture to defend needs the independent-substrate shape.

What peer reviewers actually look for

The AICPA's peer review program has a specific set of independence-focused testing procedures the reviewer runs against a sample of engagements. The procedures evolve as the practice landscape evolves. In 2025-2026 the procedures increasingly ask about tooling — specifically, about the platform's ability to modify the auditee's state and about the firm's controls around that ability.

• Sample the platform's write-scope capabilities.: The peer reviewer asks the firm's tooling lead to demonstrate what the platform can and cannot write to the auditee's environment. Where write capabilities exist, the reviewer looks for firm-level controls disabling them for attestation clients.
• Review a sample of engagement letters against the platform's actual usage on those engagements.: If the engagement letter specifies attestation-only work but the platform's logs show the auditor invoking a remediation workflow, that is a finding.
• Review the platform vendor's own SOC 2 report and independence attestation.: For bundled auditor-and-platform vendors, the reviewer evaluates whether the vendor's dual role is disclosed appropriately, whether the audit team's access to the platform's operational plane is controlled, and whether the platform's own SOC 2 examination — which the same vendor typically also performs — is itself independent.
• Ask about evidence integrity.: Increasingly, peer reviewers ask how the firm demonstrates that working papers have not been modified after signoff. Log-based answers are accepted but scrutinized; hash-and-anchor answers are stronger.

Independence-by-design as a buyer's checklist

The evaluation of a cyber-attest platform for its independence architecture reduces to a small number of concrete, verifiable questions. A serious platform vendor answers each in a specific, technical way; a policy-independent vendor answers with assurances.

The commercial tension

Independence-by-design is not the cheapest option on the market. Bundled vendors capture two revenue streams and can price the software layer below cost as a customer acquisition vehicle for the audit engagement. Independent-substrate vendors capture only the software revenue and must price accordingly. For a small practice weighing entry-cost, the bundled model can look attractive on the sticker price.

The tradeoff shows up over the practice's lifetime. Practices that build on the bundled model are structurally locked in to a vendor that competes with them for the audit engagement itself — the vendor can, and does, invite the firm's clients to switch to the vendor's own audit practice. Practices that build on independent substrates own their client relationships without a channel conflict. Over a five-year window, the acquisition-cost advantage of the bundled model is often offset by the churn cost of clients captured by the vendor's audit practice.

The bottom line

Independence in cyber attest is not going away. If anything, the pressure is intensifying — from the AICPA's peer review guidance, from state board inspection cycles, and from the sophisticated buyers who read the SOC 2 report and ask who audited the auditor. Practices that build on architecturally-independent platforms are structurally positioned to answer the independence question with a "no, the platform cannot" rather than a "yes, but our controls prevent it." That is the position that survives inspection, and it is the position that lets the firm compete on audit quality rather than on the vendor's marketing budget.

Architectural independence, out of the box

vCISO Lite for Auditors is architecturally independent by design. The platform has no write paths into the auditee's compliance state — evidence flows one-way from the auditee, working papers live in the auditor's tenant, remediation is not a workflow the platform offers. Evidence artifacts and working papers are hash-committed at capture time and timestamp-anchored. The vendor does not perform any attestation work of its own on customers of the platform. Built for CPA firms, QSAs, 3PAOs, C3PAOs, HITRUST assessors, and ISO 27001 lead auditors who compete on independence and audit quality.

If you are evaluating cyber-attest software and independence is a first-order requirement, or if a recent peer review flagged tooling-related independence questions, visit firm.vcisolite.com to see the read-only architecture.