IRAP (Information Security Registered Assessors Program) assessments evaluate systems as deployed in agency contexts-not vendor marketing slogans. When an Australian government buyer considers Trustholm (or any MSP SaaS), two responsibility layers matter: what the vendor ships and what the consuming organization attests.
Trustholm provides IAM evidence mapping, audit export APIs, tenant isolation documentation, and trust hub limitations. Consumers supply system security plan (SSP), incident response runbooks, pentest results, agency-specific controls, and assessment scheduling with an IRAP assessor.
Vendor responsibilities (technical artifacts)
| Area | Trustholm contribution | |------|------------------------| | Access control | SSO, MFA, RBAC, JWT tenant binding | | Logging | Security audit export; HTTP log enrichment | | Integrity | Script signing policy enforcement | | Isolation | Schema-per-tenant PostgreSQL | | Subprocessors | Documented on request in procurement |
Consumer responsibilities (governance and attestation)
| Area | Agency or MSP consumer owns | |------|----------------------------| | SSP authorship | System boundary, data flows, control inheritance | | IRAP assessment outcome | Pass/fail against agency context | | Endpoint controls | Patch, EDR, hardening beyond management plane | | Data classification | What script content and metadata may hold | | Continuity | Backup, DR, RTO/RPO for consuming system | | User training | Technician acceptable use and approval discipline |
IRAP is not a vendor badge
Completing IRAP on your system using Trustholm as a component does not mean Trustholm holds vendor-level IRAP attestation. Avoid questionnaire answers that imply vendor-level IRAP completion unless a specific assessment of Trustholm as a standalone system exists and is published.
Use language: "Trustholm supplies technical evidence; consumer IRAP assessment covers the deployed system including surrounding controls."
Data residency and sovereignty conversations
Government buyers ask where metadata, audit rows, and script content reside. Australia is the planned first region; EU hosting is by enterprise arrangement. Trustholm documents subprocessors in procurement artifacts-contractual residency is agreed in writing during onboarding, not inferred from generic SaaS marketing.
Pair residency tables with encryption in transit (TLS), customer-managed keys where applicable, and operator access restrictions on infrastructure you share or dedicate.
Practical procurement packet
- Trust hub evidence tables (Shipped/Gap)
- Architecture diagram with tenant isolation callouts
- Sample audit export redacted
- Subprocessor list and DPA summary
- Consumer responsibility matrix (this resource)
- Explicit limitations: Sentinel connector, WORM audit, vendor SOC 2 not claimed
MSPs serving government clients
If you resell managed services atop Trustholm, you may be the system owner in assessor eyes. Prepare SSP language for how your technicians use signing, approval, and export across classified versus unclassified client work practices.
Vendor engagement timeline for government pipeline
Months 1-2: request trust pack and subprocessor table. Months 2-3: Govern early access with security engineering reproducibility tests.
Months 3-4: draft consumer responsibility matrix and IR runbook cross-references. Months 4+: assessor workshops with export walkthrough.
Do not compress diligence because marketing copy sounds reassuring-IRAP and ISM reviews reward evidence discipline and explicit gap disclosure over speed.
Classified versus unclassified technician workflows
MSPs serving mixed government clients should document whether technicians use separate Trustholm tenants, separate customer groups, or separate approval chains for classified work. Export evidence must match the system boundary your assessor evaluates-do not reuse unclassified export samples for classified SSP appendices.
Pair technical separation with physical and personnel controls your agency customer expects beyond vendor scope.
Trust hub cross-reference
See /govern/compliance/au/irap-readiness and /govern/resources/data-residency-australia-msp-saas for companion procurement material. Vendor IRAP attestation is not claimed.
Appendix: evidence reproduction steps
Assign a reviewer to open Govern early access tenant, navigate documented UI paths, and capture screenshots with timestamps. Export audit JSON for same session.
Store in immutable GRC folder. Compare results to this article quarterly.
When Shipped/Gap rows change in trust hub, re-run reproduction within ten business days. Attach limitations memo for WORM audit and Sentinel connector backlog.
Include DB operator access policy from hosting provider. Pair technical evidence with customer governance documents-policies, pentest summaries, IR runbooks.
Never substitute marketing copy for reproduced checks in front of assessors. Treat this appendix as a living runbook section owned by security engineering, not a one-time audit artifact.
Schedule annual refresh aligned with trust hub version stamps and major product releases. Link each reproduction run to a change ticket for traceability.
Distribute updated article PDFs to customer-facing teams when dateModified changes. Archive prior versions for twelve months to support assessor lookback questions.
When citing this article externally, include dateModified and pillar metadata in footnotes so readers know content freshness. Internal enablement should link pillar tags to trust hub sections for consistent customer messaging.
Add article slug to internal wiki index for sales engineering quick lookup during live questionnaire calls.