The SOC 2 Availability Default Findings Engine is a requirement-aware template layer for AICPA Trust Services Criteria - Availability. It helps a team define consistent starting language for recurring findings while the normal project remains the source of truth for scope, evidence, ownership, remediation progress, validation, and reports.
Library and standards scope
The Availability category applies when the service organization makes commitments about systems being available for operation and use. Readiness work may cover capacity, monitoring, backup, restoration, recovery, environmental safeguards, incident handling, and tests of continuity arrangements, alongside the Security foundation.
Global, local, and project layers
- Global defaults are standards-based templates published by voiqq platform owners for a system Library.
- Local defaults belong to the signed-in workspace administrator and can override editable wording without changing the global source.
- A project finding receives copied template values and then becomes an independent record.
- Later global changes do not silently rewrite a local override or a finding already created in a project.
- Status is Open and validation is Pending when the reusable default is applied, unless an authorized project workflow later changes them.
Fields and canonical mapping
Each template is owned by a canonical availability criterion in the SOC 2 Availability Library. The reusable record contains a stable identifier, summary, description, remediation guidance, severity key, mapped values, source Library, and display order. The visible wording can be edited locally, while the background requirement identity continues to support filters, reports, imports, and New Finding suggestions.
Create or customize a default
- Confirm that Availability is part of the service commitments and project scope.
- Locate the exact Availability criterion in the local engine.
- Distinguish the recurring control gap from one incident or one missing file.
- Describe the reusable expected evidence and control outcome.
- Add remediation that can be adapted to the service architecture and recovery objectives.
- In the project finding, record the actual systems, recovery metrics, test date, and evidence.
Writing rules for reusable findings
Write the summary as a concise statement of the recurring failure. Use the description to explain the expected behavior, likely impact, or control concern in neutral language. Use remediation to describe the desired outcome rather than a patch tied to one framework or customer. Store actual results, reproduction steps, affected assets, evidence, people, dates, measurements, samples, and environment details in the project finding.
Suitable template subjects
- Backup restoration tests do not cover the systems, frequency, or recovery objectives in scope.
- Secondary regions or critical dependencies are absent from availability monitoring evidence.
- Capacity thresholds are not defined, reviewed, or connected to response actions.
- Business continuity exercises do not test the required participants or scenarios.
- Availability incidents lack timely root-cause review and tracked corrective action.
Use a default in a project
Open New Finding inside a project configured with SOC 2 Availability. Choose Template mode or select a prepared template after choosing the applicable availability criterion. voiqq prefills the reusable values. Review every field, add the real evidence and context, and save the finding. Comments, attachments, assignments, history, validation, sharing, exports, and reports then use the same normal project workflow.
Accuracy and safety checks
- Do not invent recovery objectives or uptime commitments.
- Keep service names, regions, incidents, and dates in project records.
- Distinguish missing evidence from a failed restore or ineffective control.
- Align the template to the selected project period.
- Validate corrective action with current evidence.