Apexlyn

Trust Centre

This page provides the public technical security posture for APEXLyn Attest and Trace. It is published for CISOs, auditors, insurers, procurement officers, government and banking evaluators, MSP technical reviewers, and other qualified evaluators who need specific detail before making a platform decision. Every value on this page reflects the production architecture. Security documentation containing additional implementation detail is available under appropriate review.

Request security documentation

Data hosting

AWS Sydney (ap-southeast-2)

Encryption at rest

AES-256 via AWS KMS

Encryption in transit

TLS 1.3

Evidence storage

WORM — Write Once, Read Many

Tenant isolation

Row-level security and per-tenant evidence chains

Access control

RBAC, deny-by-default, MFA across all tiers

Data retention

Tier-based and contract-defined

Audit logging

Immutable, Australian-resident, retention-governed

Australian Data Residency

All data processed and stored by the core APEXLyn Attest and Trace production platforms remains in Australia. This is enforced through infrastructure and deployment controls, not policy statements alone. The following controls are in production.

Control areaPrimary hosting region
Implementation detail
AWS Sydney — ap-southeast-2
Control areaSecondary / recovery region
Implementation detail
Australian-region recovery capability where applicable
Control areaEvidence object storage
Implementation detail
Australian-region storage with public access blocked
Control areaEvidence object access
Implementation detail
Restricted to authorised application and service paths
Control areaDatabase hosting
Implementation detail
Amazon RDS PostgreSQL within private network boundaries
Control areaDatabase exposure
Implementation detail
No public database endpoint
Control areaDatabase snapshots
Implementation detail
Governed by Australian-region backup and recovery controls
Control areaEvidence replication
Implementation detail
No evidence replication outside the approved Australian deployment boundary
Control areaLogging and monitoring
Implementation detail
Australian-region operational logging for the core production platform
Control areaProduction data in CI/CD
Implementation detail
Customer production data is not used as ordinary development or test data
Control areaThird-party processing
Implementation detail
Restricted through approved privacy, security, subprocessor, and residency requirements
Control areaGovernance communications
Implementation detail
Secure review links and governance communications follow approved data-handling requirements

If future regional deployments are launched, each region maintains its own database, its own evidence storage, its own ledger continuity, and its own tenant isolation. No cross-region evidence replication occurs.

Encryption

LayerData at rest — evidence objects
Standard
AES-256
Implementation
AWS KMS-backed server-side encryption
LayerData at rest — database
Standard
AES-256
Implementation
Encrypted database storage using AWS KMS
LayerData at rest — secrets
Standard
AES-256
Implementation
Credentials and secrets stored in encrypted secrets-management services
LayerData in transit — external
Standard
TLS 1.3
Implementation
Public and portal-facing traffic
LayerData in transit — internal
Standard
Authenticated encrypted transport
Implementation
Applied to sensitive internal service paths
LayerKey management
Standard
AWS KMS
Implementation
Controlled key administration, rotation, and access
LayerCustomer-managed keys
Standard
Available
Implementation
Supported for entitled Enterprise, Sovereign, and Government / Bank deployments

Key administration and protected-data access are separated through role-based controls. Detailed key policies, identifiers, permissions, and rotation procedures are provided through controlled security documentation.

Evidence Immutability and Integrity

Both platforms treat committed evidence as tamper-evident, traceable proof. Evidence integrity is protected through storage, ledger, cryptographic, application, and governance controls.

MechanismObject storage
Detail
S3 Object Lock in Compliance mode provides WORM-protected evidence storage
MechanismEvidence ledger
Detail
Evidence history is append-only
MechanismHash algorithm
Detail
SHA-256 is applied to committed evidence and approved reports
MechanismHash chaining
Detail
Each tenant maintains its own evidence chain
MechanismEvidence context
Detail
Evidence retains applicable timestamp, source, tenant, scope, and identity or device context where available
MechanismTenant binding
Detail
Evidence is associated with the authorised tenant and evidence source
MechanismCommit integrity
Detail
Evidence is treated as committed only after the required integrity controls complete successfully
MechanismDuplicate protection
Detail
Ingestion controls prevent unintended duplicate commitments
MechanismCorrections
Detail
Corrections create a new evidence event; the original record is not silently overwritten
MechanismReport integrity
Detail
Approved report hashes are recorded when reports are generated
MechanismTamper detection
Detail
Changes to committed chained evidence can be detected through integrity verification

If evidence requires correction or additional context, a new record is appended. The earlier record remains part of the evidence history.

Verify a report now

Tenant Isolation

Isolation layerDatabase
Implementation
PostgreSQL Row-Level Security enforces tenant-scoped access
Isolation layerEvidence chains
Implementation
Each tenant maintains a separate evidence chain
Isolation layerEvidence objects
Implementation
Evidence objects are stored and accessed within the authorised tenant context
Isolation layerConnectors
Implementation
Connector instances and credentials are associated with the authorised tenant
Isolation layerReports and exports
Implementation
Reports and exports are generated only for the applicable tenant and authorised scope
Isolation layerGovernance workflows
Implementation
Attestations, risk decisions, approvals, and review history remain tenant-specific
Isolation layerAudit logs
Implementation
Security and governance events retain tenant context
Isolation layerBackground processing
Implementation
Scheduled and asynchronous processing operates within authorised tenant scope
Isolation layerMSP access
Implementation
MSP access is limited to explicitly assigned customer tenants and authorised functions
Isolation layerPortfolio access
Implementation
Portfolio views do not automatically provide unrestricted access to underlying tenant evidence

Automated isolation testing is part of the release process. Tests include: tenant A cannot read tenant B objects (including via JOIN queries), MSP can only view assigned tenants, injection and abuse attempts are rejected and logged. All failed isolation tests block release.

Access Control and Authentication

Tenant Access and Operating Models

Every customer operates within an APEXLyn tenant. Access depends on the organization’s authorized operating model.

Operating modelCustomer-managed tenant
Access position
The organization manages its authorised users, roles, evidence scope, reporting access, and governance workflows
Operating modelMSP-managed customer tenant
Access position
An authorised MSP manages explicitly assigned customer tenants and permitted functions
Operating modelInsurer / broker program
Access position
Contract-defined policyholder, underwriting, reporting, claims-context, or portfolio workflows
Operating modelEnterprise deployment
Access position
Direct enterprise tenant or controlled deployment according to contracted scope
Operating modelGovernment / bank deployment
Access position
Controlled, dedicated, or isolated deployment according to procurement and security requirements
Operating modelAPEXLyn support access
Access position
Separate from customer and partner roles; controlled, time-limited, purpose-specific, and logged

No direct customer is placed beneath an MSP hierarchy.

Tenant-Level RBAC Roles

Tenant Admin | Approver | Reviewer | Viewer

Viewer

Read-only access to authorized dashboards, evidence views, framework results, and generated reports

Reviewer

Reviews evidence, findings, report previews, and governance requests

Approver

Performs authorized attestations, risk acceptance, approvals, and governance actions

Tenant Admin

Manages tenant users, authorized configuration, connectors, reporting permissions, and approved workflows

Authorisation Model: Deny-by-Default

Every protected action must explicitly permit the applicable role. Where access is not explicitly permitted, access is denied.

Authorisation decisions are enforced server-side. The user interface presents the actions authorised by the platform but does not independently determine access.

Authentication Controls

ControlMFA requirement
Specification
Required across APEXLyn access tiers
ControlSupported MFA methods
Specification
TOTP and WebAuthn/FIDO2
ControlMFA re-check triggers
Specification
Sensitive actions including approvals, exports, connector changes, and scope changes
ControlSession security
Specification
Controlled session duration, renewal, and termination
ControlToken protection
Specification
Rotation, expiry, and invalidation controls
ControlFailed-login protection
Specification
Account lockout and abuse-prevention controls
ControlMFA recovery
Specification
Controlled, identity-verified, and audit-logged recovery process
ControlEmergency access
Specification
Restricted, strongly authenticated, time-limited, and logged
ControlMSP suspension
Specification
Access revocation applies across assigned tenants and authorised functions
ControlSSO capability
Specification
Supported where entitled and configured
ControlSCIM capability
Specification
Supported where entitled and configured

Exact thresholds, token behaviour, recovery procedures, and emergency-access limits are maintained in controlled security documentation.

Audit Logging

All security-relevant actions across Attest and Trace are recorded in an immutable, Australian-resident audit log. Audit events cannot be altered or deleted after recording.

Audited actions

Authentication events

Login success, login failure, MFA challenge, and MFA result

Session lifecycle

Session start, renewal, logout, and termination

Role and permission changes

Role assignment, role removal, and permission changes

Connector lifecycle

Connection, disconnection, credential rotation, and consent changes

Evidence actions

Evidence ingestion and evidence commitment

Export actions

Export requests, generation, and authorised downloads

Governance actions

Attestation, risk acceptance, approval, review, expiry, and termination

Scope changes

Framework, evidence-scope, and assessment-scope changes

Support access

Support request, approval, session activity, and termination

Sensitive administration

Authorised elevated or portfolio-level administrative activity

Audit Record Principles

PrincipleActor attribution
Detail
Events identify the responsible user or service
PrincipleTenant context
Detail
Events retain the applicable tenant boundary
PrincipleTimestamping
Detail
Events record when the activity occurred
PrincipleResult recording
Detail
Success or failure is retained
PrincipleResource context
Detail
The affected resource or workflow is identified
PrincipleImmutability
Detail
Audit history is protected from ordinary alteration
PrincipleRetention
Detail
Governed by tier, contract, legal hold, and applicable policy
PrincipleCustomer visibility
Detail
Tenant-relevant audit history is available according to role and entitlement

Detailed audit-event fields, storage architecture, correlation logic, and monitoring rules are provided through controlled security documentation.

Retention and Legal Hold

AspectStandard retention
Detail
As stated for the applicable product and tier on the Pricing page
AspectProfessional retention
Detail
As stated for the applicable product and tier on the Pricing page
AspectEnterprise retention
Detail
Extended retention available according to entitlement and contract
AspectSovereign / Government / Bank retention
Detail
Contract-defined retention profiles
AspectLegal hold
Detail
Supported where entitled and configured
AspectCase hold
Detail
Preserves evidence associated with an authorised investigation or matter
AspectTenant hold
Detail
Preserves relevant evidence across an authorised tenant scope
AspectExternal hold
Detail
Supports authorised external legal or regulatory preservation requirements
AspectHold behaviour
Detail
Relevant evidence is preserved beyond ordinary lifecycle rules
AspectHold release
Detail
Requires an authorised and recorded release process
AspectOffboarding
Detail
Governed by contract, entitlement, retention, legal hold, and lawful deletion requirements
AspectLawful deletion
Detail
Applied through the approved data-lifecycle process where legally permitted
AspectRetention in reports
Detail
Applicable retention posture may be included in generated reports

Legal hold, preservation services, matter activation, extended retention, exports, and offboarding rights are governed by the applicable entitlement and contract.

Report Verification

Approved reports generated by Attest or Trace can have their hash recorded in the evidence ledger at generation. The report-verification endpoint allows authorised reviewers to confirm approved verification metadata without platform access.

Verification endpoint response

When queried with a valid report identifier, the endpoint returns:

Report identifierstring

Unique report identifier

Report hashsha256

SHA-256 hash of the generated report

Generation timestampdatetime

Time the report was generated(UTC)

Framework versionsstring

Framework versions and assessment scope bound to the report

Scopestring

Assessment scope represented by the report

Ledger confirmationstring

Confirmation that the report hash is recorded in the evidence ledger

Statusstring

Valid or Invalid

Governance Proof

Human governance decisions—including attestation, risk acceptance, approval, review, and termination—are preserved as evidence-backed governance events.

FieldActor identity
Description
Identity and authorised role associated with the action
FieldTimestamp
Description
Time the governance action occurred
FieldAction type
Description
Attestation, risk acceptance, approval, review, expiry, or termination
FieldApplicable scope
Description
Relevant framework, evidence scope, or report context
FieldEvidence association
Description
References to applicable evidence where appropriate
FieldReport association
Description
Association with an approved report where applicable
FieldReason and ownership
Description
Recorded for risk acceptance and exception workflows
FieldExpiry and review
Description
Applied where the governance action is time-bound
FieldHistory
Description
Changes create additional history rather than silently replacing the original action

Risk-acceptance workflows include documented reasons, ownership, expiry, and review. Expired or terminated decisions remain part of the governance history.

Report Structure

Reports generated by Attest support two readability modes from the same governed evidence base.

Readability Modes

Executive / Insurer View(default)

Plain English. Minimal jargon. Designed for board members, executives, insurers, and non-technical reviewers. Technical identifiers appear only when referenced in the Evidence Appendix.

Technical Appendix View

Full evidence proof: cryptographic hashes, timestamps, event IDs, device identity, ledger references. Designed for auditors, CISOs, and technical reviewers who need to verify the evidence chain.

What Reports Include

Report componentExecutive summary
Purpose
Plain-language scope, date, and assessment context
Report componentFramework scorecards
Purpose
Status and key areas requiring attention
Report componentTop risks
Purpose
Priority risks in accessible language
Report componentFindings
Purpose
Requirement, status, explanation, and remediation
Report componentAssessment coverage
Purpose
Assessed areas, exclusions, and missing evidence
Report componentEvidence appendix
Purpose
Approved evidence and integrity references
Report componentGovernance appendix
Purpose
Attestations, risk acceptance, and approval context
Report componentData-residency statement
Purpose
Applicable deployment and evidence-storage posture
Report componentIntegrity statement
Purpose
Report-integrity and evidence-chain context
Report componentReport hash
Purpose
SHA-256 report-integrity reference
Report componentQR verification code
Purpose
Included where verification is enabled
Report componentEvidence freshness
Purpose
Current, stale, missing, or insufficient status
Report componentAssertion statement
Purpose
What the report assessed
Report componentNon-assertion statement
Purpose
What the report did not assessed due to scope or insufficient evidence.
Report componentDefinitions
Purpose
Relevant terms and acronyms defined.

Every finding includes: (1) what failed, in plain English; (2) why it matters, expressed as risk; (3) what to do next, with specific remediation guidance tied to the control record; and (4) evidence reference with cryptographic hash and event ID. Reports are generated server-side only — never in the browser. The generated PDF is stored in AU-region storage and its hash is recorded as a governance or evidence event.

Confidence-Calibrated Assessment

Attest does not produce binary pass/fail results from incomplete or questionable evidence. Every control assessment includes a confidence evaluation.

A control produces PASS only when confidence is HIGH — meaning:

  • Evidence is present
  • Evidence is fresh (within the defined validity window for that control)
  • Evidence is complete (all required evidence types are present)
  • Evidence is structurally valid
  • Evidence is from the correct source
  • Evidence is within scope

If any of those conditions is not met, the output is UNKNOWN (insufficient evidence), not PASS. Missing required evidence never produces a passing result. This is a hard platform rule that cannot be overridden.

NOT_ASSESSED is used only for intentional scope exclusions — controls that are deliberately out of scope for the tenant's configuration. NOT_ASSESSED is never used to hide insufficient evidence.

Canonical status values

PASSCompliant

All required evidence is present, fresh, valid, and confidence is HIGH

FAILNon-Compliant

Evidence is present and evaluation determines non-compliance

UNKNOWNInsufficient Evidence

The available evidence cannot prove this.

NOT ASSESSEDOut of Scope

This was intentionally outside the agreed assessment scope.

EXCEPTIONException

Governance-approved exception with documented reason, owner, and expiry date

UNKNOWN means: "The available evidence cannot prove this." NOT ASSESSED means: "This was intentionally outside the agreed assessment scope." These outcomes remain separate so insufficient evidence is not presented as a passing result or hidden as an intentional exclusion.

Operational Security

AreaUptime target
Detail
99.9%
AreaRPO / RTO
Detail
Defined according to service tier or contract
AreaIncident response
Detail
Documented security, privacy, evidence-integrity, and availability response processes
AreaEvidence preservation during incidents
Detail
Relevant operational evidence is preserved for authorised investigation
AreaBackup and recovery
Detail
Defined backup, snapshot, retention, recovery, and restoration controls
AreaVulnerability management
Detail
Application, dependency, infrastructure, and secret-scanning controls
AreaChange control
Detail
Controlled approval, release, versioning, rollback, and governance history
AreaEnvironment separation
Detail
Development, staging, and production environments are separated
AreaSupply-chain security
Detail
Software dependency, build-integrity, and infrastructure-review controls
AreaCode and artifact integrity
Detail
Controlled signing and integrity validation for distributed components
AreaRate limiting
Detail
Tenant, user, and service-level request controls
AreaWeb application protection
Detail
Web Application Firewall applied to public-facing endpoints
AreaSecrets management
Detail
Production credentials and secrets stored in encrypted secret-management services
AreaConnector security
Detail
Least-privilege connector access and credential-lifecycle controls

Detailed infrastructure policies, security findings, incident procedures, recovery configurations, and operational runbooks are available only through controlled evaluation.

Data Handling and Privacy

AreaPII minimisation
Detail
Sensitive information is minimised where practical
AreaData classification
Detail
Evidence payloads and identifiers are classified for appropriate handling
AreaRedaction and masking
Detail
Applied where appropriate to collection, processing, or reporting
AreaEvidence protection
Detail
Evidence is encrypted and tenant-scoped
AreaReport redaction
Detail
Sensitive content is restricted from generated reports where required
AreaCredential protection
Detail
Connector and service credentials are encrypted and access-controlled
AreaRetention
Detail
Data lifecycle follows tier, contract, legal-hold, and legal requirements
AreaLawful deletion
Detail
Applied through the approved data-lifecycle process where legally permitted
AreaData breach response
Detail
Data-breach response procedures are maintained
AreaAustralian privacy obligations
Detail
Applicable Privacy Act and Notifiable Data Breaches obligations are supported

APEXLyn product capabilities do not replace legal, privacy, audit, regulatory, or professional advice.

Support Access Model

Our technical support and engineering teams do not have standing access to your evidence storage or governance records.

Zero Standing Privileges

No APEXLyn employee has standing read access to tenant evidence storage. Access to tenant configurations requires just-in-time approval, is time-limited, and requires a documented support-ticket reference.

Support Auditability

Any action taken by authorised APEXLyn support personnel on a tenant configuration is recorded in the tenant’s audit history. You have visibility over APEXLyn support interactions with your environment.

Assurance Roadmap

We are committed to independent verification of our own infrastructure.

Penetration Testing

We undergo regular CREST-certified penetration testing. Executive summaries of our most recent test results are available to qualified evaluators upon request.

Formal Certification

While our platform maps evidence to ISO/IEC 27001 and Essential Eight for our customers, APEXLyn itself is progressing toward formal ISO/IEC 27001:2022 certification for our own operations.

Framework Alignment Notice

APEXLyn Attest & Trace does not claim certification, accreditation, or formal compliance on behalf of an organization. Attest does not replace qualified professional advice. Assessment outputs are evidence-based, confidence-calibrated, scope-bound, and version-bound. They should be reviewed by appropriately qualified professionals for formal compliance, audit, regulatory, and legal decisions.

Where a framework requirement depends on policies, training records, contracts, consents, attestations, or other governance evidence that is not available through approved evidence paths, Attest does not treat that requirement as PASS. The platform reports it as UNKNOWN — Insufficient Evidence or excludes it from the agreed assessment scope where appropriate.

Need More Detail?

If you are evaluating APEXLyn for an enterprise, government, banking, insurance, MSP, healthcare, legal, education, or regulated-industry deployment and require information beyond what is published on this page, additional documentation is available under appropriate review.

Request security documentation

Available to qualified evaluators. Response within two business days.