We ran ourselves through our own product

Our security page says we are not ISO 27001 certified. That is true and it is the easiest sentence in the world to write, so here is the harder version: all 93 Annex A controls, where The Art of Service Pty Ltd actually stands on each one, and the reason for every verdict.

15 of them we do not meet at all. They are listed by name below, not summarised away. If you are evaluating us and one of them matters to you, you now know before you talk to us rather than after.

20
Met
41
Partial
15
Not met
10
Inherited
7
Not applicable

Inherited means a named sub-processor operates the control and we rely on them; each row says which one. Claiming Hetzner's datacentre perimeter as our own control would be the kind of overstatement this page exists to avoid. Partial mostly means the thing happens but nothing about it would survive an auditor asking for evidence. Reviewed 20 August 2026.

Organizational controls

5.1Policies for information securityPartial

Public commitments exist in the security statement, DPA, privacy policy and terms. There is no internally approved information security policy set, and no review cycle for one.

5.2Information security roles and responsibilitiesPartial

Roles are unambiguous because the team is very small, but they are not written down or formally assigned.

5.3Segregation of dutiesNot met

Not achievable at this size. The same person develops, deploys and administers production. Compensating controls are version control and an audited deploy path, not separation.

5.4Management responsibilitiesPartial

Management and operations are the same people, so direction is not the constraint; documented evidence that it happened is.

5.5Contact with authoritiesPartial

The company is registered with the OAIC regime as an Australian entity and the DPA carries a 72 hour notification commitment. No standing contact is maintained with a CERT.

5.6Contact with special interest groupsNot met

No membership of a security forum or industry special interest group.

5.7Threat intelligenceNot met

No threat intelligence feed is consumed. Dependency advisories arrive through GitHub only.

5.8Information security in project managementPartial

Security is considered in change design, but there is no project methodology gate that records it.

5.9Inventory of information and other associated assetsPartial

The estate is small and fully known: three servers, one graph database, one Redis, one frontend host. There is no maintained asset register.

5.10Acceptable use of information and other associated assetsNot met

No acceptable use policy has been issued.

5.11Return of assetsNot applicable

No employees hold company assets that would be returned. Contractors have no issued equipment.

5.12Classification of informationPartial

Customer compliance data and account data are treated as the sensitive classes and separated in handling. The scheme is not documented.

5.13Labelling of informationNot met

No labelling scheme exists.

5.14Information transferMet

Transfers to sub-processors are over TLS and each is covered by the DPA, which names them, their purpose, the data they see and their location.

5.15Access controlPartial

Access to production is restricted to one operator by SSH key. There is no documented access control policy behind that.

5.16Identity managementMet

Platform identities are unique per account, issued through SSO or password registration, and API keys are per account and revocable.

5.17Authentication informationPartial

Passwords are hashed and API keys are secrets shown once. Accounts not using SSO have no second factor, which the security page states plainly.

5.18Access rightsPartial

Rights are provisioned and removed by the one operator. There is no periodic review of who holds what, because there is one holder.

5.19Information security in supplier relationshipsMet

Every sub-processor is named publicly with purpose, data and location, and adding one requires 30 days notice under the DPA.

5.20Addressing information security within supplier agreementsPartial

The DPA binds us to our customers. We rely on each provider's standard terms upstream rather than negotiated security schedules.

5.21Managing information security in the ICT supply chainPartial

The ICT supply chain is short and named. Component and dependency provenance is not formally assessed beyond GitHub advisories.

5.22Monitoring, review and change management of supplier servicesNot met

No scheduled review of sub-processor security posture takes place. Changes are noticed reactively.

5.23Information security for use of cloud servicesPartial

Cloud use is deliberate and documented publicly, and data residency is stated. There is no cloud security policy governing the choice.

5.24Information security incident management planning and preparationPartial

A 72 hour breach notification commitment exists contractually and a reporting address is published with a two business day acknowledgement. There is no tested incident plan.

5.25Assessment and decision on information security eventsPartial

Events reaching the operator are assessed. There is no defined triage criteria or severity scheme.

5.26Response to information security incidentsPartial

Response would be immediate and by one person. It is not documented or rehearsed.

5.27Learning from information security incidentsPartial

Defects found in operation are written up in detail and the reasoning is kept, which is where the learning goes. This is engineering practice rather than a security incident review.

5.28Collection of evidenceNot met

No forensic evidence handling procedure exists.

5.29Information security during disruptionPartial

The platform degrades rather than fails: the frontend serves cached content when the API is unreachable. There is no continuity plan for the company.

5.30ICT readiness for business continuityPartial

Daily database dumps with seven day retention support recovery. Single region, and restore has not been exercised on a schedule.

5.31Legal, statutory, regulatory and contractual requirementsMet

Australian law and GDPR obligations are identified and carried into the DPA and privacy policy, which are published.

5.32Intellectual property rightsMet

Third party standards are referenced, never reproduced. Where a licensed copy is not held the platform says so rather than publishing text it does not have the right to.

5.33Protection of recordsPartial

Records are retained in the database and backups. There is no records retention schedule beyond the 30 day deletion commitment.

5.34Privacy and protection of personal identifiable information (PII)Met

Personal data handling is set out in the privacy policy and DPA, with deletion within 30 days on request and written confirmation, and no model training on customer data.

5.35Independent review of information securityNot met

No independent review of information security has been commissioned. No penetration test, no audit, no attestation.

5.36Compliance with policies, rules and standards for information securityNot met

There are no internal policies to check compliance against.

5.37Documented operating proceduresPartial

Operating procedures for deploy, restore and release are written and followed, in the repository rather than in a controlled document set.

People controls

6.1ScreeningNot applicable

No hiring has taken place under the current operating model.

6.2Terms and conditions of employmentPartial

Contractual terms exist for the people involved. They do not carry explicit information security responsibilities.

6.3Information security awareness, education and trainingNot met

No security awareness training programme exists.

6.4Disciplinary processNot met

No disciplinary process is defined for security breaches.

6.5Responsibilities after termination or change of employmentNot applicable

No terminations to manage under the current operating model.

6.6Confidentiality or non-disclosure agreementsPartial

Confidentiality obligations flow through customer contracts and the DPA. There is no standing NDA regime for personnel.

6.7Remote workingPartial

All work is remote by default from a small number of known devices. There is no remote working policy.

6.8Information security event reportingMet

A published reporting address with a two business day acknowledgement, and an explicit commitment not to pursue good faith reporters.

Physical controls

7.1Physical security perimetersInherited

Datacentre perimeter is operated by Hetzner Online GmbH in Germany. We hold no facility of our own containing platform data.

7.2Physical entryInherited

Physical entry control is Hetzner's.

7.3Securing offices, rooms and facilitiesInherited

Facility security is Hetzner's. No company office holds platform data.

7.4Physical security monitoringInherited

Physical monitoring is Hetzner's.

7.5Protecting against physical and environmental threatsInherited

Environmental threat protection is Hetzner's.

7.6Working in secure areasNot applicable

We operate no secure areas.

7.7Clear desk and clear screenNot met

No clear desk or clear screen practice is defined or enforced.

7.8Equipment siting and protectionInherited

Server siting and protection is Hetzner's. Workstations are not covered by any equivalent control of ours.

7.9Security of assets off-premisesPartial

Work happens on a small number of known personal devices with full disk encryption. There is no off premises asset control.

7.10Storage mediaPartial

No removable media is used for platform data. This is practice, not policy.

7.11Supporting utilitiesInherited

Power and cooling are Hetzner's.

7.12Cabling securityInherited

Cabling is Hetzner's.

7.13Equipment maintenanceInherited

Server hardware maintenance is Hetzner's.

7.14Secure disposal or re-use of equipmentInherited

Secure disposal of server hardware is Hetzner's. We have no equivalent process for our own end user devices.

Technological controls

8.1User end point devicesPartial

End points are few, known and disk encrypted. There is no endpoint management, no enforced configuration and no mobile device policy.

8.2Privileged access rightsPartial

Privileged access is one operator holding one SSH key. Concentration rather than control: there is no approval or review of privilege.

8.3Information access restrictionMet

Access to customer data is restricted per account and enforced in the API. Paid artefacts are bound to the purchasing token rather than to a guessable identifier.

8.4Access to source codeMet

Source is in a private repository with access limited to the operator; deploys run from a pinned remote with a fast forward only merge.

8.5Secure authenticationPartial

SSO through Google or Microsoft inherits the customer's own MFA. Password accounts have no second factor, stated plainly on the security page.

8.6Capacity managementPartial

Capacity is monitored informally and the estate is far below its limits. There is no capacity plan or alerting threshold.

8.7Protection against malwareNot met

No anti malware runs on the servers. The workload is a database, an API and a reverse proxy with no user file execution, which is a reason and not a control.

8.8Management of technical vulnerabilitiesPartial

Dependency advisories are received and acted on. There is no vulnerability scanning of the running estate and no external penetration test.

8.9Configuration managementMet

Infrastructure is defined in compose files and configuration in version control, so the running configuration is reproducible from the repository.

8.10Information deletionMet

Personal and compliance data are deleted within 30 days of a request or termination, confirmed in writing, as committed in the DPA.

8.11Data maskingPartial

Advisory queries sent for inference are anonymised and not retained. No masking is applied elsewhere.

8.12Data leakage preventionNot met

No data leakage prevention tooling is in place.

8.13Information backupPartial

Daily dumps at 02:00 UTC with seven day retention. One region, and restores are not tested on a schedule.

8.14Redundancy of information processing facilitiesNot met

No redundancy. One database on one host in one region. The frontend is redundant because Vercel is, which is not our doing.

8.15LoggingPartial

Application and access logs are produced and retained on the host. There is no central log store and no tamper protection.

8.16Monitoring activitiesPartial

Health and error monitoring exist. There is no security monitoring or alerting on anomalous access.

8.17Clock synchronizationMet

Hosts synchronise time through the operating system's NTP, so log timestamps are comparable.

8.18Use of privileged utility programsPartial

Privileged utilities are available to the one operator on the host. Their use is not restricted or logged separately.

8.19Installation of software on operational systemsMet

The API image bakes its code, so what runs is what was built and deploying is a rebuild rather than an in place change.

8.20Networks securityMet

Only 80 and 443 are exposed. Database, cache and API listen on the internal Docker network and are unreachable from outside.

8.21Security of network servicesMet

All external traffic is TLS terminated at Caddy with certificates issued and renewed automatically, plus HSTS with preload.

8.22Segregation of networksMet

Application services sit on an internal network with no public route; only the reverse proxy bridges the two.

8.23Web filteringNot applicable

No corporate network or user browsing to filter.

8.24Use of cryptographyMet

TLS in transit, encrypted volumes at rest, passwords hashed, API keys and entitlement tokens generated from a cryptographic random source.

8.25Secure development life cyclePartial

Changes go through version control, typechecking and a test gate before deploy. There is no documented secure development lifecycle.

8.26Application security requirementsPartial

Authentication, authorisation and input handling are treated as requirements in design. They are not captured as written security requirements per change.

8.27Secure system architecture and engineering principlesMet

Least exposure by default: internal networks, no public database, single use tokens, ownership checks on every artefact a buyer can reach.

8.28Secure codingPartial

Parameterised queries throughout and user text never reaches a query language. There is no coding standard document and no static analysis in the pipeline.

8.29Security testing in development and acceptancePartial

A continuous integration gate runs typecheck and a published numbers check on every change, and functional verification is run against production after deploy. There is no security specific testing.

8.30Outsourced developmentNot applicable

No development is outsourced.

8.31Separation of development, test and production environmentsPartial

Development is local and production is remote, so they are separated. There is no staging environment between them.

8.32Change managementMet

Every change is a commit with its reasoning, deployed by an automated path that refuses to run on a dirty tree and fast forwards only.

8.33Test informationMet

Test data is synthetic. No customer data is copied into development.

8.34Protection of information systems during audit testingNot applicable

No audit testing on operational systems has been performed, since no audit has been commissioned.

How this was produced

The control list is the ISO 27001:2022 Annex A set as this platform holds it. You can pull the same 93 controls yourself from the free framework tools and check that nothing was quietly left out:

curl -sG https://api.theartofservice.com/api/agent/frameworks/ISO%2027001:2022/controls

The verdicts are ours, and they are a self assessment. Nobody independent has checked them, which is itself one of the controls we record as not met (5.35). Corrections to support@theartofservice.com. Back to the security page.