Assess the system and the business workflow
A practical evidence request for procurement, technical review and practice risk assessment.
Source reviewed Security and privacy documentation
Begin by naming the product, intended workflow, client-data categories and version or review date. Ask for evidence that applies to that scope. A general architecture diagram cannot prove that a particular access check or restore worked in the deployed system.
Technical assessment
| Area | Evidence to request or inspect | What it should establish |
|---|---|---|
| Data destinations | Current provider list, processing agreement and per-stage configuration | Where your practice's material can be processed and retained |
| Tenant isolation | Two-practice negative-access tests for records, files and server operations | One practice's credentials are refused access to another's records |
| Authentication | Account/second-factor configuration and request expiry/revocation checks | The credentials and trust boundaries of each client and firm flow |
| Outbound AI gate | Supported-format tests, identifier fixtures and failure-path evidence | Unsafe/unreadable input stops before outbound transmission |
| Workpaper delivery | Representative cases, validation results, review/repair records and output versions | What was checked and which workbook was actually delivered |
| Signing | Source hash, signer events, completed PDF and certificate | What was sent and which actions occurred, not independent identity proof |
| Verify | Provider evidence, missing/not-run components, assessments and approvals | What evidence supports the firm's CDD decision |
| Retention and recovery | Cleanup/deletion results, provider retention terms and dated restore exercise | What is removed, what remains and how recovery was tested |
| Change management | Source revision, checks for that revision and deployment marker | The evaluated change reached the environment in question |
Automated tests are useful implementation evidence. They are not an external certification, a complete security audit or a promise that every production configuration matches the tested one. Ask for the test scope, date and revision alongside the result. This documentation makes no SOC 2 or ISO certification claim.
Business and practice assessment
Define who will upload evidence, answer questions, review output, authorise communications and retain records. Check the product's boundary against the actual service your practice offers:
- Workpapers does not lodge returns; the accountant checks and lodges through their existing process.
- A signing record does not decide whether the person had authority to bind the entity or whether the agreement's terms are suitable.
- An identity result is one input to due diligence; scope, risk, further evidence and sign-off remain practice decisions.
- A BAS exception decision does not change the source ledger; agreed changes need to be made and checked there.
- Local PDF extraction is not an accounting or evidence-validation service.
Use representative cases, including missing evidence and provider failures. Confirm the team can recognise incomplete results and recover without treating a draft, stale result or untested rule as complete.
Request a focused evidence pack
Contact support@beforemay.com.au with your scope and the relevant rows above. Request any needed agreements and operational reports explicitly. Sensitive deployment details and client-level evidence should be shared through an agreed access-controlled channel, not published inside these public guides.
ATO/Digital Service Provider assessment material is prepared separately for the agreed review scope. Identify the intended recipient and assessment purpose when requesting it, so the applicable material and sharing arrangements can be reviewed. These public guides do not imply ATO approval or DSP accreditation.
For policy and contractual terms, read Privacy and Terms. For an incident or privacy request, use privacy@beforemay.com.au.