Independent testing
Application penetration testing by an external firm, with the summary report and the remediation status available under NDA. We share the findings, not a certificate that a test happened.
What we can reach, and what we can change.
Stratiri reads from the systems you already run. Nothing is written back without approval: a proposed action reaches the source system only after a named finance person approves it. This page sets out that boundary, the platform controls underneath it, where your records are processed, and what your security team can ask us for.
01 / Access model
Read-only by default. Write only on approval.
Most of the risk in a finance integration is not what a vendor can see. It is what a vendor can change. Stratiri is built so that the second question has a short answer.
| Boundary | What it means in practice | Where it is enforced |
|---|---|---|
| Source connections | Read-only credentials and scopes wherever a source system offers them. Where a system only issues a full-access credential, that is recorded on the integration and raised with you rather than left implicit. | Integration configuration |
| Write-back | A proposed action reaches a source system only after a named finance person approves it. Until then it stays in a queue with the evidence behind it, and the approval is part of the record. | Application and audit log |
| Banking credentials | Held by the open-banking or aggregation provider, not by Stratiri. Where a token has to be stored, it is encrypted under a key scoped to your tenant and never returned through the API. | Managed secret store |
| Tenant isolation | Every query carries the active organisation. Row-level policies reject a request that arrives without one, so isolation does not depend on application code remembering to filter. | Database policy |
| Derived figures | Balances, explanations and proposed actions keep a reference to the records they were built from, so any number on screen can be resolved back to a source document. | Financial model |
| Our own access | Support access to tenant data requires a named request, is time-boxed, and is logged against the engineer who opened it. It is not a standing capability. | Access control and audit log |
The ERP stays authoritative. Stratiri is a layer above your systems of record, not a replacement for them. If our figure and your ledger disagree, the ledger is right and the difference is something we have to explain.
Actions are proposals until someone signs them. A payment run, a dunning message or a ledger adjustment prepared by Stratiri is inert until a person with the authority to approve it does so, in their own name.
02 / Platform controls
The controls your assessment will ask about.
Set out here rather than sent as a PDF after the third email. If your questionnaire needs a different format, we will complete it against the integration actually in scope.
| Encryption in transit | TLS 1.2 or higher on every external connection, with HSTS on the application. Traffic between internal services stays inside the provider network. |
|---|---|
| Encryption at rest | AES-256 across databases, object storage and backups. Keys are managed by the cloud provider’s key service; stored source credentials take an additional key scoped to your tenant. |
| Identity | SAML and OIDC single sign-on for enterprise tenants, with SCIM provisioning so joiners and leavers follow your directory. Multi-factor authentication is mandatory on every Stratiri staff account. |
| Authorisation | Role and capability checks on every route, mapped to the separations finance already runs on: who can view, who can prepare, who can approve. Signing in establishes identity, not authority. |
| Audit logging | Authentication, permission changes, exports and approvals are recorded with actor, tenant and timestamp, and retained for the life of the contract. Exportable for your own review. |
| Backup and recovery | Point-in-time recovery on the primary datastore and daily snapshots held for thirty days. Restores are exercised on a schedule, not assumed to work. |
| Change management | Peer review and automated checks on every change. Schema migrations are reviewed separately from application code, and every production release traces back to a commit and an approver. |
| Vulnerability management | Dependency and container scanning on each build, provider-managed patching underneath, and a documented severity ladder with fix windows attached to each level. |
| Availability | Managed multi-zone infrastructure with health checks and alerting. Incident history and current status are shared with customers under contract. |
| Our devices | Company laptops are disk-encrypted, centrally managed and lock on idle. Access is revoked the day someone leaves, as part of the same checklist that returns the hardware. |
03 / Data location
Regional deployment options.
Stratiri is designed for regional deployments across major markets. Options commonly align to Europe, the United States or Asia-Pacific, subject to the services available for the agreed architecture. Exact provider locations, data flows and contract terms are confirmed before the first connection, and we notify you before the sub-processor list changes.
| Function | What it does | Regional availability |
|---|---|---|
| Application database | Primary record store, tenant isolation policies, object storage and backups | Agreed deployment region |
| Application hosting | The product itself and the request layer in front of it | Aligned to deployment |
| Scheduled processing | Ingestion runs and the batch jobs that rebuild the financial model | Aligned to deployment |
| Model inference | The reasoning behind Shared Intelligence, called per question | Approved provider region |
| Transactional email | Sign-in links, notifications and approval requests | Region-aware service |
Your data does not train anyone’s model. Questions asked in Shared Intelligence, and the records retrieved to answer them, are sent to the inference provider under terms that exclude training and retention. Nothing about your business improves a model anyone else uses.
Residency is a contract term, not a preference. Where a group needs processing confined to a named region, that is agreed before the first connection is made and reflected in the deployment, not managed by policy after the fact.
04 / Assurance
Evidence, and how to get it.
What a reviewer usually wants before they will sign anything. All of it is available; none of it requires you to be a customer first.
Certification status
Confirmed to you in writing at the start of a review, against a dated position. We do not print badges for standards we are still working towards, and we will tell you plainly where we are.
Incident notification
Written notice within twenty-four hours of confirming an incident that affects your data: what we know, what we do not yet know, and when the next update lands.
Responsible disclosure
Report a vulnerability to security@stratiri.com. We acknowledge within one business day, keep you updated while we fix it, and will not pursue good-faith research.
Questionnaires
SIG Lite, CAIQ or your own template, answered against the integration in scope rather than a generic platform description. Turnaround is usually under a week.
Contractual terms
Data processing agreement with standard contractual clauses, the sub-processor list above, and change notification with a window to object before a new one is used.
05 / Vendor review
Start the review before the pilot, not after it.
The answers depend on which systems you connect and which actions you want prepared, so a generic assessment tends to ask the wrong questions. We work through it in this order.
Review sequence
Scope first.Claims should match the integration actually under review. Four sessions with your security team, usually inside two weeks.
- 01Data and source inventoryRecords·systems·regions
- 02Identity and access designUsers·roles·capabilities
- 03Integration boundariesCredentials·scopes·movement
- 04Evidence and responsibilitiesReview·ownership·contacts
Security review contact. security@stratiri.com reaches the engineer who would run your integration, not a shared inbox. Send the questionnaire and we will tell you what we cannot answer before you find out yourself.
Related. Privacy covers what we hold and for how long. Developers covers the API surface, authentication and tenant scoping in detail.