Existing audit work should not have to be retyped before a team can manage it properly. A spreadsheet may already contain hundreds of findings, controls, evidence requests, remediation owners, or retest records. The challenge is converting that information into a structured project without silently changing its meaning or trapping it in an imported-only view that cannot use normal assignments, drawers, reports, and validation.
The problem this guide solves
Workbooks are rarely uniform. A cover sheet may contain merged cells and summary metrics, another tab may hold the real findings table, and a third may track evidence. Headers vary by profession, organization, and language. Simple name matching can put Summary into Actual Result, Control Owner into Assignee, or a documentation URL into Page URL. Empty source columns can also clutter the project while important dormant fields remain hidden.
Understand the standard and the boundary
A trustworthy import process separates the original-grid snapshot from normalized project records. It analyzes each sheet, identifies a regular header row and repeated record structure, asks the user to choose the Program and Library, and maps only fields supported by the source evidence. Canonical identifiers such as WCAG criteria, SOC 2 controls, ASVS requirements, MASVS controls, or AISVS requirements should be matched against the selected Library rather than accepted as arbitrary text.
Review the spreadsheet import documentation
Who this workflow helps
- Auditors moving an established tracker into a collaborative workspace.
- Teams combining workbooks received from several consultants.
- Students importing sample assessment data for structured practice.
- Organizations standardizing historical findings across Programs and languages.
A professional workflow
A dependable assessment does not begin with a report button. It begins with a clear question, defined scope, the correct standard, suitable test methods, and a record that another authorized reviewer can follow. The sequence below is designed to preserve that chain. Adapt its depth to the engagement, but do not remove the review decisions merely to make the process appear faster.
- Keep an unchanged backup of the source workbook.
- Upload XLSX or CSV, or provide a public Google Sheets URL.
- Review every sheet classification and exclude covers, dashboards, pivots, and irregular notes.
- Choose Program, Library, metrics, language, and project name for each included sheet.
- Review automatic column matching using headers and representative cell values.
- Preserve ambiguous columns and correct any mapping that does not fit the actual data.
- Create the projects, compare sample rows with the source, and review report-critical mappings.
What to record
Record enough information to support reproduction, assignment, remediation, validation, and reporting. Each field should have one clear purpose. Keep identifiers and quoted evidence exact, distinguish observations from recommendations, and avoid collecting secrets or personal information that the work does not require. A smaller complete record is more useful than a large collection of disconnected text and files.
- Workbook and sheet names, original headers, column order, row order, values, and widths where available.
- Chosen Program, Library, project metrics, source type, and content language.
- Canonical mappings with confidence and warnings.
- Normalized Summary, requirement, severity, status, validation, assignee, due date, and remediation where supported.
- Additional imported data that does not belong to a standard field.
- Import source details and timestamp for later review.
How voiqq supports the work
voiqq uses one project and finding foundation across Programs while each Library controls its own requirements, fields, metrics, mapping, automation boundary, and report rules. That means teams can reuse assignments, comments, evidence, validation, history, permissions, imports, exports, and recovery without pretending that every standard reaches the same kind of conclusion.
voiqq analyzes multi-sheet workbooks and creates one normal project for each included structured sheet. Its deterministic Program configurations cover Accessibility, SOC 2, ASVS, MASVS, AISVS, and future Libraries, while high-confidence AI classification is reserved for genuinely ambiguous columns. The source grid remains available, empty nonessential columns can stay hidden, and normalized fields power the existing table, drawer, assignments, reports, exports, and recovery behavior.
Quality checks before sharing
- Compare the first, middle, and last imported rows with the source.
- Check every requirement or control mapping before generating a report.
- Verify that visible labels did not change the canonical background identity.
- Confirm Status, Validation, Evidence Status, Assignee, and Control Owner remain distinct.
- Delete a test import and restore it before importing a critical production workbook.
Before distribution, ask a second question beyond whether the file generated: can the intended reader understand the scope, trace important statements to project evidence, distinguish active and resolved work, and see the limits of the conclusion? Review permissions and attachments as carefully as report wording. Preserve an approved snapshot when the deliverable must remain stable after the live project changes.
A practical next step
Test the import engine with a copy of one real workbook. Include its cover and summary tabs so sheet classification is exercised. Review the resulting project and one draft export, then document any organization-specific aliases or fields before migrating the remaining portfolio.
Treat the first result as a review draft. Check it with the people who perform the work and the people who receive the outcome. Their questions will reveal missing context, confusing terminology, weak permissions, and report assumptions sooner than another decorative dashboard will. Improve the project model, then repeat the same disciplined workflow.