Agency data handling
How Decla handles agency data: what to request and verify
Before your agency connects mailboxes, file storage or an agency management system to Decla, check three things against each other: what Decla has published, what your signed agreement commits to, and what the configured account does in a scoped trial. Where they disagree, record the gap and ask which document governs.
Back to the security overview
On this page
Ask for each answer on retention, deletion, hosting location, AI providers, certifications and credential storage in writing, and note where it comes from: Decla's dated privacy policy, your executed agreement, your account's written configuration or its security documentation. Use this page to ask for them, test what a trial can show, and know which question each piece of evidence settles.
Three layers of evidence
| Layer | What to request | What it can show | What it cannot show |
|---|---|---|---|
| Published policy | The current privacy policy and any data-processing terms Decla identifies as current, with effective dates | The stated commitments and which version is in force | Whether those commitments are in your signed agreement or reflected in your account's configuration |
| Executed agreement | The signed agreement and any data-processing addendum, with execution dates | The obligations accepted for your agency and when they took effect | Whether a particular system or AI provider is actually used for your tasks |
| Written configuration | Written configuration for your account: retention, training-use, region and routing settings | What the account is documented as set to | That the setting is operating as written, or that it covers infrastructure you could not observe |
| Trial | A trial using the roles, folders and approvals you plan to grant | What the system did under the settings you tested | Behavior outside the tested scope, or infrastructure controls you could not observe |
A document marked draft is a proposal, not an executed term. Ask for the version that governs your agency.
Ask about service data and AI providers separately
These are different questions, answered by different documents. One answer does not cover the other.
Service data is what Decla's own service keeps for your agency, such as account records, uploaded documents, task history and outputs. Ask which of these are kept, the retention and deletion schedule for each, how backups and records from connected systems are handled, the export format and window, and what happens at offboarding. Ask which dated agreement governs each answer.
AI provider processing is what happens when a task sends content to a model provider. Ask which providers and endpoints would handle your agency's content, whether they keep inputs or outputs and for how long, whether that content can be used for model training, and which executed agreement covers each provider. A provider named in a document does not show that it handles your tasks; ask for the routing configuration for your account.
Contract terms such as zero retention or no training can apply only to certain providers, endpoints or configurations. Ask which condition applies to your account. If health information could be in scope, ask which path it would take and whether an executed business associate agreement covers that path before any is sent.
Separate written assurances from what a trial can show
Some answers can only come from documents: how connection credentials are stored, how prompts are isolated and how prompt injection is defended against. Request the security documentation and any independent assessment, and check its scope and period. Others, such as AI provider retention, training use, hosting region and deletion after termination, cannot be observed in a trial at all. A written configuration or confirmation describes those settings; it does not prove them. A written statement remains a statement until it is independently assessed or, where the behavior is observable, tested.
Other answers can be observed in a trial with your own setup:
- Role-specific account. Create a user with the role you plan to grant and confirm what that user can see and change.
- Least-access folder scope. Limit the file-storage folders the trial can read, for example in SharePoint or OneDrive, and confirm the workflow stays inside them. Confirm before the trial that this restriction is available for your setup.
- Approval limits. Confirm which actions require human approval in your configuration. Approval applies where it is configured, not automatically to every action.
- Bulk-write gates. Confirm whether bulk updates to your agency management system are blocked, capped or held for approval, and who can change that setting.
The folder and bulk-write checks come from security questions agencies have raised with us: one asked to limit a trial to specific SharePoint and OneDrive folders and requested security documents for its IT team; another raised hard-to-undo bulk writes and confidential-client permissions in its agency management system.
Each test proves only what you tested. A role-specific account test does not show where credentials are stored, whether prompt injection is blocked, or whether your agency management system enforces confidential-client permissions inside its own integration toolkit. Ask about each of those separately.
Verification table
| Question | Documentary evidence to request | What a trial can actually show | What neither proves |
|---|---|---|---|
| How long is service data kept, and when is it deleted after termination? | Retention and deletion schedule in the executed agreement; written deletion confirmation for a closed trial account | Not observable in a trial | That every backup or log was deleted on schedule |
| Can the agency export its documents and task history? | Export specification and offboarding procedure | A test export from a trial workspace, checked for all files and task records | Full-scale or backup export |
| Do AI providers keep inputs or outputs, and for how long? | Executed provider terms, the current provider list with dates, and the written retention setting for your account’s endpoint | Not observable in a trial | That a listed provider handles your tasks, or that provider retention matches service-data retention |
| Can agency content be used to train models? | Executed provider and data-processing terms covering training use, and the written training-use setting for each endpoint | Not observable in a trial | That a policy, draft or written setting reflects an executed term operating as written |
| Where is data hosted and processed? | Hosting and processing locations in the agreement, and written confirmation of your account’s region | Not observable in a trial | Backup locations, support access or provider processing |
| How are connection credentials stored? | Security documentation and any independent assessment, with scope and dates | Whether revoking a test connection stops that connection’s access | How or where credentials are stored |
| Are prompt-injection risks addressed? | Security documentation and the scope of any assessment | Whether the workflow follows instructions placed in a labeled test document | Resistance to other injection attempts, or how prompts are isolated internally |
| Who can see trial data, and which folders can the trial reach? | Role list and access-control description | What a role-specific account can see and change, and whether the trial stays inside a restricted test folder | Infrastructure access controls, or anything beyond the tested role and folders |
| Are bulk writes to the agency management system gated? | Approval and write-limit configuration | Whether a bulk update attempted in a test environment you control is blocked, capped or held for approval | Permission enforcement inside the management system’s own toolkit |
| Who can access agency data remotely, from where, and how is access recorded? | Access policy listing the locations and roles your agreement covers, and a sample access record for the trial account | Not observable in a trial | That the policy operates as written at all times |
| Which audit or certification applies, and to what scope? | Current audit report with scope, period and covered entities, checked against the service you are buying | Not observable in a trial | Anything outside the stated scope; a logo or badge alone establishes nothing |
Request list to send
Copy this into your request to Decla and record who answered each item and on what date.
- The current Privacy Policy and any data-processing terms, with effective dates.
- The executed agreement and data-processing addendum, with execution dates and no draft markings.
- The current provider and subprocessor list, with its date and the agreement it falls under.
- Service-data retention, export and deletion procedures, including backups and connected-system records.
- AI provider retention, training-use and endpoint configuration for your account.
- Hosting and processing locations, and the roles and locations with remote access.
- Security documentation and any audit report, with scope and period.
- The role, folder and approval configuration for your trial, in writing.
Then run the role, folder, approval and bulk-write checks in a scoped trial, and connect your systems once the three layers agree. Do not paste credentials into task instructions; connect only through the method your agreement and configuration specify.
Frequently asked questions
How does Decla handle agency data?
Before your agency connects mailboxes, file storage or an AMS to Decla, check three things against each other: what Decla has published, what your signed agreement commits to, and what the configured account does in a scoped trial. Where they disagree, record the gap and ask which document governs.
What is Decla?
Decla is AI software for independent insurance agencies and brokerages. It connects to your AMS, email and carrier portals and does back-office work inside them. Your team reviews the work before it goes out.