Security
Security
Fund Analyst Intelligence is designed for production use in environments where data access and accountability matter.
Security is treated as an operational requirement.
It is implemented through controlled access, clear separation, and auditable actions.
This page describes the security posture and typical controls.
It is written to support partner risk reviews and deployment decisions.
Security objectives
A production deployment should ensure:
- only authorised users can access fund data and artefacts
- access is logged and attributable
- environments are separated appropriately
- evidence and reports are stored securely and consistently
- operational failures do not create data exposure
Access control
Role-based access
Access is granted by role and scope.
Typical roles include:
- operator: runs cycles and prepares drafts
- reviewer: resolves exceptions and approves outputs
- read-only: consumes reports and dashboards
- administrator: manages policies, roles, and configuration
Role definitions should match the partner’s operating model.
Separation of duties can be enforced where required.
Least privilege by default
Users should only see what they need to do their job.
Fund access can be restricted by portfolio, region, strategy, or client group.
Administrative privileges should be limited and reviewed.
Tenancy and data separation
Fund Analyst Intelligence is designed to support strong separation between clients and environments.
Typical separation expectations
- logical tenancy separation for organisations
- portfolio-level scoping within an organisation
- isolation between development, staging, and production environments
- controlled access to evidence and exported artefacts
The appropriate model depends on deployment type and partner requirements.
The goal is to prevent cross-tenant visibility and accidental leakage.
Data handling
Artefacts and evidence
Source documents and evidence packs are treated as sensitive artefacts.
They are stored and accessed under explicit permissions.
They retain provenance metadata for audit and reproducibility.
Structured fund data
Extracted fields and claims are stored as structured data.
They are linked to evidence references rather than duplicating sensitive content unnecessarily.
Retention policies can be applied to both raw artefacts and derived data.
Data minimisation
Security is improved by collecting what is needed and nothing more.
Partners should define:
- required artefacts for validation scope
- retention periods
- allowed storage locations
- export and sharing rules
Logging and auditability
Security relies on strong logs.
A production deployment should log:
- authentication events
- access to sensitive fund artefacts
- changes to policies (source allow-lists, materiality thresholds)
- reviewer approvals and manual overrides
- exports and report publication events
- administrative role changes
Logs should be attributable and time-stamped.
They should support internal reviews and incident response.
Secure output handling
Reports and evidence packs often become client-facing artefacts.
Security requires a clear publication model.
Partners typically define:
- where reports are published and stored
- who can publish
- whether exports are allowed outside the platform
- how long outputs are retained
- how revoked access affects historical artefacts
Outputs should carry approval stamps.
Unapproved drafts should not be published.
Operational security
Safe failure behaviour
When a cycle fails, the system should:
- fail explicitly and log the failure
- avoid partial publication states
- preserve input inventories and draft artefacts safely
- support controlled reruns with clear versioning
Monitoring
Production monitoring should include:
- failed cycle runs and error classification
- unusual access patterns
- missing or stale input detection
- export volumes and publication events
Security is operational.
It requires visibility.
Third-party and integration security
Integrations must preserve security properties.
Typical requirements:
- authenticated API access
- versioned contracts
- least-privilege integration scopes
- audit logs for exports and downstream pushes
- encryption in transit for all integrations
If partners integrate document stores or CRMs, roles and retention must remain aligned.
The goal is to avoid “secure core, insecure edge”.
Partner responsibilities
Security is shared.
The platform supports controls, but partners define policy and operational practice.
Partners typically own:
- user provisioning and access reviews
- role definitions and separation of duties
- retention policies and archival rules
- incident response process and escalation owners
- approval standards for publication and export
Definition of done
Security readiness is production-grade when:
- access is role-based and least-privilege
- tenant and environment separation is clear
- artefacts and evidence are stored under controlled permissions
- logging is attributable and comprehensive
- publication and export are governed by approval states
- monitoring supports operational detection and response
This is the baseline for deploying Fund Analyst Intelligence with confidence.