Security and trust
Responsibility across the full lifecycle
Trust is supported by defence in depth, least privilege, evidence, recovery and honest communication about what has and has not been verified.
Associated Ventures protects information and services through proportionate technical and operational controls. No control eliminates all risk, and no public page should be read as a certification or guarantee.
Security principles
- Defence in depth: use multiple independent layers so one failure is not the whole control.
- Least privilege and need to know: grant the smallest access needed for an approved purpose.
- Explicit authority: identify who may request, approve and perform consequential actions.
- Human accountability: automation supports evidence and workflow; it does not own judgement.
- Separation of duties: avoid one unchecked identity controlling a sensitive outcome.
- Secure defaults and fail-safe behaviour: deny or degrade safely when a dependency, identity or validation is uncertain.
- Recovery readiness: plan restore, rollback and handover before failure.
- Evidence and privacy by design: record useful events while minimising unnecessary personal detail.
- Honest reporting: public claims match deployed reality, measurement perspective and known limitations.
Shared responsibility
Associated Ventures defines boundaries, chooses proportionate controls, reviews readiness, protects records and communicates known incidents or limitations. Individual ventures retain responsibility for their customers, commitments, content and lawful obligations. Staff and authorised operators protect credentials, follow approvals, report anomalies and avoid copying information into unapproved systems. Customers and account holders protect their sign-in factors, use approved channels and report suspected compromise. External providers remain responsible for their systems, terms, resilience and evidence; an integration does not transfer all accountability. Professional advisers retain their specialist duties. Security researchers should test minimally, avoid harm and report responsibly.
Identity and access
Customer and staff identity boundaries are separate. Private functions require authenticated identities, role-based authorisation and stronger authentication for sensitive staff or administrative actions. Controls may include MFA, session expiry, reauthentication, account lockout, device/session revocation and one-time approvals. Shared credentials are prohibited for accountable access. Sensitive access and administrative decisions should be auditable.
Public staff sign-in, open registration and unrestricted customer access are not implied by the existence of a portal. Functions remain restricted or in preparation until identity, support, privacy, recovery and approval gates are complete.
Information classification
Handling requirements increase with sensitivity:
Information lifecycle
Collection is purpose-limited and validated. Use is restricted to the approved outcome. Access and sharing follow role, authority and need to know. Storage and transmission use controls proportionate to sensitivity. Exports are authorised, minimised and traceable. Backups and recovery preserve availability without becoming an ungoverned copy. Retention and deletion follow purpose, legal, incident and operational requirements. Decommissioning removes access, credentials, data and provider connections in a controlled way.
Encryption and key responsibility
HTTPS protects approved public transport when correctly configured. Sensitive stored information may require encryption at rest. Keys must be separated from ordinary application data, access-restricted, protected, rotated and recoverable under independent authority. Encryption does not replace identity, authorisation, audit, malware controls, backups or operational discipline. Algorithms, key locations and recovery mechanisms are intentionally not published here.
Application security
Secure development includes input validation, output encoding, CSRF protection where browser sessions apply, secure cookie attributes, rate limiting, session protection, dependency review, sanitised errors, IDOR resistance, injection resistance, safe path handling, upload validation, security headers, Content Security Policy and browser regression tests. Automated tests provide evidence for tested cases; they are not independent certification.
Files and attachments
Where a file service is active, declared and detected type, size, integrity hash, quarantine state and malware result are considered before authorised retrieval. Unsafe, unsupported, oversized or tampered content is rejected or quarantined. Downloads are authorised and auditable; retention and controlled deletion apply. Production upload services remain inactive where the status page says they are in preparation or validation.
Infrastructure and network boundaries
Public services are limited to their intended web entry points. Administrative systems are not intended for direct public access. Databases and protected storage remain behind application boundaries. Services are separated by role and trust requirement, and public health information is sanitised. Additional separation is introduced as services mature. Topology, addresses, ports, products and physical locations are deliberately not published.
Monitoring and audit
Useful telemetry may include availability, security events, authentication, administrative actions, sensitive access, changes and approvals, file activity, incidents and backup state. Detailed telemetry is restricted and logs should redact unnecessary personal information. Audit records should be protected against casual alteration and retained only as long as their purpose requires.
Incident response
Public reporting balances transparency with protection of customers and systems. Sensitive exploit details are not published while they could increase harm.
Backup, recovery and continuity
Recovery planning identifies priorities, dependencies, acceptable degradation and responsible decisions. Backups are encrypted where appropriate, integrity-checked, retained and separated from live systems. Significant changes have recovery points and documented rollback. Restore testing uses controlled destinations and verifies data consistency. Off-site or hardware redundancy is not claimed unless specifically verified.
Physical security
Authorised physical access, asset accountability, controlled maintenance, secure handling and disposal, environmental and power considerations, detection of unauthorised interference and hardware-loss recovery are part of the lifecycle. Physical locations, tamper-trigger designs and destructive mechanisms are not published.
Supplier and provider security
Providers are considered for minimum permissions, protected credentials, privacy and contractual fit, integration isolation, monitoring, revocation, export and portability, provider-failure planning and unnecessary lock-in. An adapter should not silently own authoritative data. External providers retain their own security and privacy responsibilities.
Privacy and personal information
See the Privacy page for the detailed notice. The operating approach is purpose-limited collection, minimisation, accuracy and correction, role access, retention/deletion, controlled disclosure, breach assessment and secure communication. Never send credentials or identity information through an unverified public message.
Responsible security reporting
Use the verified contact route and provide the affected public URL, concise reproduction steps, observed impact, time and safe remediation idea. Do not perform privacy invasion, disruption, social engineering, physical intrusion, credential attacks, persistence or destruction. This is good-faith coordinated disclosure guidance, not a funded bug bounty or blanket authorisation. See security.txt and the detailed reporting policy.
Assurance and limitations
No system is described as unhackable. Passing automated tests is not independent certification. Controlled validation is not production activation. Controls evolve with risk and service maturity, and independent professional testing remains important. Certifications are not displayed unless genuinely held. Public summaries intentionally do not disclose complete internal controls.
Security questions
Is customer information publicly accessible?
Public pages are designed not to expose customer records. Private access must be authenticated and authorised; no public page is a promise that every future service is active.
Are staff and customer portals the same system?
They are separate access classes with different roles and controls; public staff activation is not implied.
Is MFA required?
Private and sensitive functions require stronger authentication appropriate to their risk; specific service readiness is shown publicly.
Are files scanned and backups tested?
Where the relevant service is active, scanning, quarantine, integrity and restore verification are part of the intended lifecycle. Validation services remain labelled as such.
How are incidents handled?
Detect, validate, contain, assess, notify appropriately, recover, verify, review and improve.
Why are some services In preparation?
Because identity, support, privacy, security, recovery, provider or ownership gates are incomplete.
How are sensitive exports controlled?
By purpose, minimum content, authorised recipient, protected channel, audit and retention/deletion controls.
How can I make a privacy request?
Use the verified contact pathway; send only minimum identifying information until a controlled channel is agreed.
Glossary
- Least privilege
- Only the access needed for an approved task.
- Authentication
- Establishing which identity is requesting access.
- Authorisation
- Checking whether that identity may perform the requested action.
- Defence in depth
- Multiple protective layers so one failure is not the whole control.
- Quarantine
- Holding content away from release while its safety is assessed.
- Recovery point
- A preserved state from which a service or record can be restored.
Last substantive review: 1 September 2026. No certification claim is made.
Information and access lifecycle
Information is classified from public through operational, customer-confidential, staff-restricted, security-sensitive and highly protected or Vault-controlled. Handling requirements increase with sensitivity: collect only what is needed, validate it, limit access, protect transmission and storage, retain it for a defined purpose, then securely delete or decommission it.
Security in practice
Controls include separate customer and staff boundaries, MFA-ready identity, role-based access, session expiry, reauthentication, lockout, device and session revocation, secure cookies, validation, output encoding, CSRF protection, rate limiting, dependency review, path protection, upload limits, security headers, CSP, monitoring and regression testing. Files may be hashed, quarantined and scanned before authorised retrieval; unsupported or unsafe content is rejected. Production upload availability is stated on the relevant service page.
Monitoring, incidents and recovery
Availability, authentication, administrative actions, sensitive access, changes, file activity, incidents and backup state are logged with privacy-aware redaction and restricted telemetry access. Response proceeds through detection, validation, containment, evidence preservation, impact assessment, appropriate notification, recovery, verification, review and improvement.
Backups are integrity-checked and restores are tested in isolation. Recovery points precede significant changes, live systems are separated from backups, and rollback is documented. No claim is made about unverified off-site or hardware redundancy.
Supplier, privacy and reporting
Providers are assessed for permissions, privacy, monitoring, revocation, portability and failure planning. See Privacy for purpose limitation, correction, access, retention and disclosure. Security concerns should use the reporting route in security.txt; do not test by invading privacy, disrupting services, social engineering or destroying data.
Assurance and limitations
No system is described as unhackable. Automated tests are not independent certification, controlled validation is not production activation, and public summaries do not disclose complete internal controls. Security evolves with risk and service maturity.
Security questions
Are staff and customer portals the same?
No. Access classes and permissions are separated; private staff functions are not presented as public customer access.
Are backups tested?
Restore verification is a required operating practice; current status is reported only when evidence is available.
How can a vulnerability be reported?
Use the verified route in security.txt and include reproducible, non-destructive details without sending credentials or personal information.