Agree the security and data-handling requirements before the build
A project proposal should make its operating assumptions visible. That includes who can access information, where systems run, which suppliers process data and what evidence your organization needs before approval. FI Digital discusses these requirements as part of scoping rather than treating a website statement as a substitute for due diligence.
Define the information and the people involved
Begin with the categories of information the workflow uses and the people who need access. Identify the systems that own the records, the actions the implementation will perform and the roles responsible for approving changes. Sensitive data should not be sent through an initial website inquiry.
The engagement should document relevant access arrangements, environments and responsibilities. Where delivery involves people in different countries, that arrangement and any restrictions need to be assessed explicitly. A US-facing website does not establish that every person or system involved is located in the United States.
FI DIGITAL / ILLUSTRATIVE WORKFLOW
A useful health check ends in a clear decision
A proposed review method, with delivery scoped separately.
Evidence, business ownership and acceptance matter more than a generic score.
- 1 / Trace the failureUse an operating example. Inspect configuration, data and interfaces.
- 2 / Decide what to repairRecord evidence and business impact. Agree priorities, dependencies and owners.
- 3 / Make approved changesUse a defined test and change process. Keep the recovery approach documented.
- 4 / Verify the original problemRun the agreed acceptance scenarios. Review the result with the operating team.
Review hosting and suppliers for the actual scope
Hosting region, platform settings and supplier terms depend on the proposed architecture and purchased services. Confirm them for the particular engagement. A provider offering a US region does not, by itself, establish where every support activity, log or connected service is processed.
The same care applies to retention and deletion. The parties should identify which records, backups and operational logs exist, who controls them and which requirements apply. Do not assume that a broad description of a platform covers every configured feature or third-party connection.
Make AI responsibilities explicit
An AI workflow needs a defined purpose, permitted information, allowed actions and a route for human review. Agree how representative cases will be evaluated and what happens when an answer is uncertain, an action fails or a request falls outside scope.
Model training use, retention and logging are different questions. Review the current terms and settings of each selected service before making a commitment about any of them. The project should also identify who approves changes to prompts, models, connected tools and the boundaries of autonomous action.
Request evidence that matches your procurement requirements
If your organization requires an assurance report, certification, insurance document or specialist agreement, raise that requirement early. The responsible team must confirm what is currently available and whether it covers the proposed scope. This page does not claim SOC 2 certification, a universal compliance status or that a particular agreement is available for every engagement.
The contract and supporting documents should identify responsibilities for implementation, operation, incident handling and changes. Where legal or regulatory interpretation is required, involve the appropriately qualified adviser. Our role and any technical commitments must be established in the agreed engagement.
Begin with a requirement list
Tell us which information the proposed workflow will handle, your required hosting or access restrictions and the evidence your procurement team expects. We can then assess the requirements with the relevant technical and commercial owners before delivery is approved.
Frequently asked questions
Does this page mean FI Digital has a SOC 2 report?
No. This page describes topics to assess for an engagement and does not claim an issued SOC 2 report or certification. If your procurement process requires a particular assurance document, request it directly and verify its current scope, reporting period and relevance before treating the requirement as satisfied.
Will every workload and team member be in the US?
That is not established by this website. Hosting regions, connected services, support access and delivery locations must be confirmed for the proposed engagement. If you have restrictions on cross-border access or processing, identify them during scoping so the architecture, team arrangements and contractual responsibilities can be assessed before approval.
Will an AI provider retain information or use it for training?
Those are separate questions that depend on the selected provider, service, settings and contract. They must be reviewed for the actual implementation. Do not assume that a no-training provision also means no retention, or that a provider-level statement automatically covers every connected tool, logging system or support process.
Can an AI agent make every decision autonomously?
The permitted actions and human-review boundaries should be defined for the specific workflow. Some decisions may always require a qualified person or business approver. Evaluation should test representative and exceptional requests, while the operating design needs a way to escalate, recover from failures and suspend actions when necessary.
Can you sign a BAA or other specialist agreement?
Availability and suitability must be assessed by the responsible legal and commercial owners for the actual scope. This page does not promise that a particular agreement can be signed for every project. Identify the requirement before sharing regulated information or approving work that depends on the agreement being in place.
Who owns the code and project materials?
Ownership, usage rights, access and handover obligations belong in the written agreement. The terms should distinguish newly created deliverables from pre-existing components, open-source software and third-party services. Do not rely on a general marketing statement to determine rights that depend on the commercial scope and licensing conditions.
How should access be arranged during implementation?
The project should identify who needs access, for what purpose, to which environments and for how long. Approval, changes and removal should have named owners. The actual controls and evidence need to match the agreed requirements; this page does not certify that every possible control has already been implemented across all engagements.
What should procurement request before approval?
Provide your requirement list early, including applicable assurance documents, hosting restrictions, supplier terms and incident or support expectations. Ask the responsible team to identify available evidence and unresolved gaps. Review those answers against the proposed scope with your technical, privacy and legal owners before treating a supplier requirement as fulfilled.