PYRON Trust Centre
ASD Essentials for cloud: shared responsibility
Every action in ASD's Essentials for cloud, with who holds it, what Pyron provides and what you switch on.
The Australian Signals Directorate's Essentials for cloud, published on 15 October 2026, sets out what an organisation that runs on cloud services should do, and marks each action with who typically holds it: the customer, the provider, or both, where the provider supplies a capability the customer must switch on and run. This page takes every action in ASD's matrix and says what Pyron does for it and what is yours to do.
- Responsibility is ASD's marker for software as a service: Pyron (ASD's Provider), Shared (ASD's Supplied) or Customer. ASD's matrix gives one action, PRO-09.2, no marker.
- Status is where Pyron's part stands today: for a Pyron action, the action itself; for a shared one, what Pyron supplies; for a customer action, what Pyron offers to help, or Not applicable where the action is yours alone. Planned means it is not in place today.
- Your part is what you do or switch on. ASD's guidance is that a capability left at an insecure default is not yet effective.
- Reference is ASD's principle identifier, which traces to the Information Security Manual, then the action's place under that principle in ASD's matrix: ASD numbers principles, not actions.
Pyron lets you build pages and automations of your own. ASD suggests that an organisation making significant use of capabilities like these also weigh the platform-as-a-service markers; this page uses the software-as-a-service markers throughout.
ASD expects a provider's part to be confirmed with independent assurance, such as an IRAP assessment. Pyron has none yet, so this is our own account, checked against production on the date above. The Security overview says how each control works, and Data locations where each kind of data is held.
The action wording is ASD's, from ASD Essentials for cloud, © Commonwealth of Australia 2026, under the Creative Commons Attribution 4.0 International licence.
- In place
- 39
- Partial
- 21
- Planned
- 4
- Not applicable
- 14
Showing 78 of 78
| Reference | Requirement | Status | Responsibility | How we meet it |
|---|---|---|---|---|
| GOV-01.1 | Executive cyber security accountability: Formally define and establish executive and board-level accountabilities for cyber security, including setting, monitoring and adjusting organisational risk appetite, and review these accountabilities at a defined cadence. | Not applicable | Customer | Your organisation's own, with no part for Pyron. |
| GOV-08.1 | Executive artificial intelligence accountability: Establish and maintain executive accountability for the use, governance and risk management of artificial intelligence within the organisation. | In place | Customer | In Setup, admins see what the workspace's AI has spent, set monthly AI budgets for the workspace, each role, each person and each automation, and answer requests for more. An automation that uses AI runs as an account an admin chose, and does only what its approved version declares. Your part: name the executive accountable for your use of AI, and give them Setup's AI pages. |
| GOV-08.2 | Executive artificial intelligence accountability: Require executive or delegate approval before enabling material SaaS or PaaS AI functions, including review of accessible data, permissions, retention, logging, agents and connectors. | In place | Customer | Pyron AI works with the permissions of the person asking: it sees only what they can see, and its activity is recorded on the audit trail like any other actor's. Customer data is not used to train foundation models. Anything Pyron AI would delete, publish, send or use to grant access waits for the approval of the person it is acting for, with a preview of what it will do. Pyron AI runs behind Amazon Bedrock Guardrails, which check what people ask for prompt attacks and harmful content, and check its answers for harmful content and credentials. An intervention steers the AI back on course and is recorded. In Setup, admins see what the workspace's AI has spent, set monthly AI budgets for the workspace, each role, each person and each automation, and answer requests for more. An automation that uses AI runs as an account an admin chose, and does only what its approved version declares. Your part: decide who approves using Pyron AI for new kinds of work. What the AI can reach is what the roles of the person using it can reach, so review those roles. |
| GOV-04.1 | Cyber security resourcing: Assign sufficient cyber security personnel and resources with the required skills to operate, monitor, maintain and manage the lifecycle of controls across cloud services, and define cyber security responsibilities within role descriptions. | Not applicable | Customer | Your organisation's own, with no part for Pyron. |
| GOV-04.2 | Cyber security resourcing: Periodically review cyber security resourcing against cyber threat trends, cyber security incident outcomes and organisational changes. | Not applicable | Customer | Your organisation's own, with no part for Pyron. |
| GOV-09.1 | Security risk management responsibilities: Adoption of high-risk SaaS or PaaS services that store sensitive data or support critical business functions requires executive approval. | In place | Customer | This Trust Centre publishes our security overview, where each kind of data is held and these self-assessments, openly and each with a version and a date. Your part: have an executive approve adopting Pyron, on what this Trust Centre publishes. |
| GOV-09.2 | Security risk management responsibilities: SaaS or PaaS platforms that organisations configure, monitor, assure or operate, express security requirements as a condition of use. | In place | Customer | This Trust Centre publishes our security overview, where each kind of data is held and these self-assessments, openly and each with a version and a date. Your part: state your security requirements in your agreement with us. |
| GOV-09.3 | Security risk management responsibilities: Shared responsibility arrangements for cloud services are understood, documented and incorporated into security risk management activities. | In place | Shared | This Trust Centre publishes our security overview, where each kind of data is held and these self-assessments, openly and each with a version and a date. Your part: bring this matrix into your risk management, and record where your use of Pyron differs from it. |
| GOV-03.1 | Security risk management assurance: Establish and maintain an approved risk management methodology and plan that is used to assess and treat cyber security and shared responsibility risks. | Not applicable | Customer | Your organisation's own, with no part for Pyron. |
| GOV-11.1 | Supplier cyber security assurance: Select and engage suppliers of software, hardware and services on the basis of a cyber supply chain risk assessment proportionate to the risk the supplier introduces, and retain appropriate assurance evidence to support the decision. | Partial | Customer | This Trust Centre publishes our security overview, where each kind of data is held and these self-assessments, openly and each with a version and a date. Every service provider that handles customer data is named on Data locations and in our Privacy Statement, with what it receives and where, and a change to that list is recorded in the statement's revision history. Pyron holds no security certification and has had no independent penetration test. Your part: assess Pyron before you engage us, and keep the documents you relied on. |
| GOV-11.2 | Supplier cyber security assurance: Maintain current, appropriately scoped assurance that suppliers continue to meet their cyber security commitments, and act when assurance lapses, excludes a service or feature in use, or the supplier’s risk changes. | Partial | Customer | This Trust Centre publishes our security overview, where each kind of data is held and these self-assessments, openly and each with a version and a date. Pyron holds no security certification and has had no independent penetration test. Your part: check this Trust Centre's versions and dates at each review. |
| GOV-11.3 | Supplier cyber security assurance: Maintain a register of inherited and retained security responsibilities per provider, and review it as services change. | In place | Customer | This Trust Centre publishes our security overview, where each kind of data is held and these self-assessments, openly and each with a version and a date. Your part: record this matrix in your register for Pyron, and review it when we publish a new version. |
| GOV-11.4 | Supplier cyber security assurance: Establish policies that meet your data sensitivity and sovereignty requirements. | In place | Customer | Your records and files are stored in Australia, and the AI runs in Australia: Pyron's services may call only Amazon Bedrock's Australian models. Every service provider that handles customer data is named on Data locations and in our Privacy Statement, with what it receives and where, and a change to that list is recorded in the statement's revision history. Your part: decide what you keep in Pyron against where each kind of data is held. |
| GOV-11.5 | Supplier cyber security assurance: Establish policies that restricts software on cloud services to reputable suppliers. | In place | Customer | Adding a connection to another service, a stored login or an API key is an operation of its own, which only a role that holds its permission can perform. Your part: decide which services your people may connect to Pyron, and give the permission to connect them only to the roles that should have it. |
| GOV-14.1 | Legacy system management: Establish and maintain a process for identifying, assessing and treating cyber security risks associated with legacy systems and unsupported technologies through compensating controls, enhanced monitoring and assurance until the systems can be removed or replaced. | Not applicable | Customer | Your organisation's own, with no part for Pyron. |
| PRO-14.1 | Cyber security awareness training: Update and provide cyber security awareness training on a regular basis to reflect current threats and operational considerations. | Not applicable | Customer | Your organisation's own, with no part for Pyron. |
| PRO-06.1 | Vulnerability management: Prioritise cloud services that maximise provider-managed security responsibilities and minimise customer-managed components, where this is consistent with organisational, security and business requirements. | Not applicable | Customer | A choice your organisation makes between services. |
| IDE-01.1 | Asset identification: Use an approved asset inventory mechanism that supports automated discovery to detect new and changed non-physical assets including short-lived containers and virtual machines. | In place | Shared | Setup lists every person, guest, service account, API key, connection, stored login, automation, shared page and role in a workspace. Every change in a workspace is recorded in plain words, whoever made it: a person, an automation, the AI or Support. What people view is recorded too, and so are attempts the permission engine refuses. The trail is kept for 24 months: records are only ever added, never edited, and each is cryptographically linked to the one before it, so tampering would be evident. Your part: review Setup's lists, and the audit trail for what was added. |
| IDE-01.2 | Asset identification: Identify sanctioned and unsanctioned services, tenants and integrations and promptly bring them under organisational governance. | In place | Shared | Setup lists every person, guest, service account, API key, connection, stored login, automation, shared page and role in a workspace. Adding a connection to another service, a stored login or an API key is an operation of its own, which only a role that holds its permission can perform. Your part: review the connections, stored logins and API keys in Setup, and remove any you did not sanction. |
| IDE-04.1 | Security risk identification: Identify relevant weaknesses, malicious actor techniques and cyber threat behaviours when undertaking risk assessments and review these inputs on a continuous basis. | Not applicable | Customer | Your organisation's own, with no part for Pyron. |
| PRO-13.1 | Identity, credential and access management: Regularly scan codebases, configuration files, file shares and user collaboration platforms to identify unsecured keys, secrets credentials and tokens. | Partial | Shared | Our code is scanned for secrets on every change, and GitHub refuses a push that contains one. Logins a workspace keeps in the Pyron Vault are stored encrypted, apart from the database. A hidden value is never shown to the AI, which reads only a hint of what it is for, and a value is only ever sent to the web addresses its login allows. Pyron does not scan the records, files or pages you keep in it for secrets. Your part: keep credentials in the Pyron Vault, never in records, files or pages. |
| DET-01.1 | Centralised event logging: Establish a centralised event log storage capability that protects logs from unauthorised access, modification or deletion. | In place | Shared | Every change in a workspace is recorded in plain words, whoever made it: a person, an automation, the AI or Support. What people view is recorded too, and so are attempts the permission engine refuses. The trail is kept for 24 months: records are only ever added, never edited, and each is cryptographically linked to the one before it, so tampering would be evident. People whose role allows it can export the audit trail, filtered or whole, as a spreadsheet or as a file for a security system (one event per line), and each export is itself recorded. Activity on our AWS accounts is recorded by AWS CloudTrail into a separate archive account, where it is locked for 12 months. Your part: if your logs must sit in a central store of your own, export the audit trail to it. |
| DET-02.1 | Cyber security event detection: Ensure detection logic identifies unauthorised changes, anomalous authentication activity and anomalous control-plane activity, including consent grants, federation changes and privilege elevations. | Partial | Pyron | A sign-in as an account's root user, use of emergency access, or a change to an organisation policy or to our cloud activity logging pages our on-call engineer; a change to who can reach our AWS accounts, and a new finding of access from outside them, raise an alert. Managed threat detection for our AWS accounts (Amazon GuardDuty), and detection of unusual sign-in patterns in Pyron, are not in place. Your part: watch the audit trail for changes to roles and to single sign-on, which it records. |
| DET-02.2 | Cyber security event detection: Baseline resource utilisation to monitor for and detect anomalous activity. | Partial | Pyron | Logs, metrics and traces from every part of the service are collected through OpenTelemetry and go to Grafana Cloud in Australia, with credentials and what is said to and by the AI removed first. Alerts watch errors, response times, database capacity, background work, certificates and credentials, and each alert has a written runbook. Alerts fire at set thresholds rather than against a learned baseline of normal use. |
| DET-03.1 | Cyber security incident identification: Triage alerts and events in a timely manner to determine whether cyber security incident thresholds have been met. | Partial | Shared | Alerts that need someone page our on-call engineer through All Quiet. On-call is one engineer, with no second line. We notify an affected customer of a suspected or confirmed security incident affecting their data without undue delay and no later than 48 hours, and assess a possible eligible data breach under the Privacy Act 1988 (Cth) within 30 days. Your part: triage what your workspace's audit trail shows. |
| DET-03.2 | Cyber security incident identification: Use available indicators from all connected sources, rather than isolated signals, when performing cyber security incident identification activities. | In place | Shared | Logs, metrics and traces from every part of the service are collected through OpenTelemetry and go to Grafana Cloud in Australia, with credentials and what is said to and by the AI removed first. Alerts watch errors, response times, database capacity, background work, certificates and credentials, and each alert has a written runbook. People whose role allows it can export the audit trail, filtered or whole, as a spreadsheet or as a file for a security system (one event per line), and each export is itself recorded. Your part: bring the audit trail into your security system beside your other sources. |
| DET-05.1 | Detection capability efficacy: Review detection coverage periodically to identify gaps arising from new cloud services, integrations or architectural changes. | Not applicable | Customer | Your organisation's own, with no part for Pyron. |
| RES-05.1 | Cyber security incident coordination: Integrate external coordination obligations and requirements into incident response activities, including provider notifications arrangements, escalation contacts and the division of investigative responsibilities under shared responsibility. | In place | Customer | We notify an affected customer of a suspected or confirmed security incident affecting their data without undue delay and no later than 48 hours, and assess a possible eligible data breach under the Privacy Act 1988 (Cth) within 30 days. Anyone can report a vulnerability to security@pyron.io, as our security.txt says. Your part: put our incident notice, and security@pyron.io, in your incident response plan. |
| RES-03.1 | Cyber security incident response: Use documented, tested and approved incident response procedures when responding to cyber security incidents, covering tenant and identity-provider compromise, provider-side incidents, token and session revocation, removal of unauthorised consent grants and validation of a trusted state before resuming operations. | Partial | Customer | A workspace admin can suspend a person, which refuses every request they make from that moment, or remove them. There is no automatic deprovisioning from an identity provider (SCIM): when someone leaves, an admin suspends or removes them in Pyron. Integrations and automations act as service accounts, each holding roles like a person. An API key belongs to one service account, is stored only as a hash, can expire and can be revoked at any time, and what is done with it is recorded on the audit trail as that account. The Incident Management Policy sets out how an incident is found, rated, contained, investigated with its evidence preserved, and learned from, who leads it and when customers are told. It took effect on 25 October 2026 and has not yet been rehearsed in an exercise. Your part: write Pyron into your procedures. Suspending a person ends their access at once, and revoking an API key stops it. |
| RES-04.1 | Cyber security incident insights: Perform post-cyber security incident reviews to identify the security gaps that enabled each stage of the cyber security incident. | Not applicable | Customer | Your organisation's own, with no part for Pyron. |
| RES-04.2 | Cyber security incident insights: Evaluate monitoring coverage and cyber security incident response procedures following cyber security incidents. | Not applicable | Customer | Your organisation's own, with no part for Pyron. |
| IDE-01.3 | Asset identification: Maintain current records of identities, non-person identities, integrations, data and cloud regions, using automated discovery where available to detect new and changed assets. | In place | Customer | Setup lists every person, guest, service account, API key, connection, stored login, automation, shared page and role in a workspace. Every service provider that handles customer data is named on Data locations and in our Privacy Statement, with what it receives and where, and a change to that list is recorded in the statement's revision history. Your part: keep Setup's lists, and Data locations, in your records. |
| PRO-01.1 | Secure system lifecycle: Develop and use a controlled process to onboard, configure and exit services, verifying data retrieval, deletion and access revocation. | In place | Shared | People can export a table's records as a spreadsheet. When a subscription ends there is a 30-day export window, then deletion within 90 days; deleting a workspace removes its database schema, its files, its stored secrets and its single sign-on connection, and backups age out on their normal rotation. A workspace admin can suspend a person, which refuses every request they make from that moment, or remove them. There is no automatic deprovisioning from an identity provider (SCIM): when someone leaves, an admin suspends or removes them in Pyron. Your part: plan your exit, and export what you need within the export window. |
| PRO-01.2 | Secure system lifecycle: Harden development pipelines and their credentials, restricting who can approve and deploy changes to production. | Partial | Pyron | Every change reaches production as a pull request, which merges only when its required checks pass: the test suites, a production build, an API contract check and a dependency scan. The team is small, and a second engineer's approval is not yet required. Static analysis runs on every change, including security rules for our code, our container files and our build workflows. Our services reach AWS through roles bound to each workload, and our build pipelines through short-lived OpenID Connect credentials, never through stored access keys. |
| PRO-01.3 | Secure system lifecycle: Identify and remediate vulnerable third-party libraries and dependencies before deployment and on an ongoing basis. | In place | Pyron | Every dependency is scanned for known vulnerabilities on each change and every day. A change that adds a high or critical advisory is blocked, and an accepted finding is recorded with its reason and an expiry, so it is looked at again. |
| PRO-16.1 | Cyber supply chain security: Assess and approve applications, integrations and consent grants before permitting access, and review them on a regular basis. | In place | Customer | Adding a connection to another service, a stored login or an API key is an operation of its own, which only a role that holds its permission can perform. Setup lists every person, guest, service account, API key, connection, stored login, automation, shared page and role in a workspace. Your part: approve each connection before it is added, and review Setup's lists regularly. |
| PRO-16.2 | Cyber supply chain security: Assess the integrity and authenticity of images, components and artefacts before they are deployed into services, and verify provenance where suitable supplier evidence is available. | Partial | Pyron | Container images are built by our pipeline from base images pinned to an exact digest, with dependencies installed from locked versions, scanned when they are pushed, and stored under tags that cannot be overwritten. Images are not signed, and their provenance is not verified when they are deployed. |
| PRO-16.3 | Cyber supply chain security: Use vendor advisories and threat intelligence to maintain awareness of supplier, product and component exposure to compromise, and act within timeframes proportionate to the risk. | In place | Shared | Every dependency is scanned for known vulnerabilities on each change and every day. A change that adds a high or critical advisory is blocked, and an accepted finding is recorded with its reason and an expiry, so it is looked at again. Your part: watch this Trust Centre for anything that affects Pyron. |
| PRO-16.4 | Cyber supply chain security: Identify and mitigate single points of dependency created by OAuth and federated identity providers. | In place | Customer | A workspace admin can connect a SAML or OpenID Connect identity provider (Microsoft Entra ID, Okta, Google Workspace and others) in Setup, test it, then allow it beside passwords or make it required. Required switches password sign-in off for everyone, with no fallback. Your part: if you make single sign-on required, your people cannot sign in while your identity provider is down. Keep it allowed beside passwords if you need a way in without it. |
| PRO-13.2 | Identity, credential and access management: Identify and disable or remove default and unused accounts on a regular basis, permitting exceptions only where the account is documented, justified, hardened and monitored. Govern emergency access accounts separately, minimise their number, securely protect their credentials, monitor their use and test them regularly. | Partial | Shared | A workspace admin can suspend a person, which refuses every request they make from that moment, or remove them. There is no automatic deprovisioning from an identity provider (SCIM): when someone leaves, an admin suspends or removes them in Pyron. Techly's support engineers can sign in to any workspace to help, only through Techly's Google Workspace, which enforces 2-step verification, and a Support session lasts at most 8 hours and cannot be extended. What Support views and changes is recorded on the workspace's audit trail. A workspace cannot yet switch this access off. Emergency access to our AWS accounts is a separate permission set, and each use of it, like any sign-in as an account's root user, pages our on-call engineer. Your part: suspend or remove people, and disable service accounts, that no longer need access, and review the People list regularly. |
| PRO-13.3 | Identity, credential and access management: Monitor services for supply chain compromise, including provider advisories and changes to security commitments, and respond in a timely manner. | In place | Shared | Every dependency is scanned for known vulnerabilities on each change and every day. A change that adds a high or critical advisory is blocked, and an accepted finding is recorded with its reason and an expiry, so it is looked at again. Every service provider that handles customer data is named on Data locations and in our Privacy Statement, with what it receives and where, and a change to that list is recorded in the statement's revision history. Your part: watch this Trust Centre and our Privacy Statement for changes to our providers and our commitments. |
| PRO-13.4 | Identity, credential and access management: Store credentials, keys, secrets and tokens in approved secure access controlled repositories, and rotate, expire or replace non-person credentials with managed or federated workload identities where supported. | In place | Shared | Logins a workspace keeps in the Pyron Vault are stored encrypted, apart from the database. A hidden value is never shown to the AI, which reads only a hint of what it is for, and a value is only ever sent to the web addresses its login allows. Integrations and automations act as service accounts, each holding roles like a person. An API key belongs to one service account, is stored only as a hash, can expire and can be revoked at any time, and what is done with it is recorded on the audit trail as that account. Our services reach AWS through roles bound to each workload, and our build pipelines through short-lived OpenID Connect credentials, never through stored access keys. Your part: keep integration credentials in the Pyron Vault, and give API keys an expiry. |
| PRO-13.5 | Identity, credential and access management: Use phishing-resistant MFA for users authenticating to systems. | In place | Shared | Two-step sign-in works with a passkey, an authenticator app or a code sent by email. A workspace admin can make it required for everyone or for chosen roles, and can switch off authenticator apps and emailed codes so that only passkeys, which resist phishing, are accepted. A workspace admin can connect a SAML or OpenID Connect identity provider (Microsoft Entra ID, Okta, Google Workspace and others) in Setup, test it, then allow it beside passwords or make it required. Required switches password sign-in off for everyone, with no fallback. Your part: make two-step sign-in required and allow only passkeys, or, if your people sign in through your identity provider, require phishing-resistant MFA there. |
| PRO-13.6 | Identity, credential and access management: Non-person identities are authorised, assigned an owner and constrained to their intended context, with use bound to trusted workload, issuer or service conditions and activity recorded. | In place | Shared | Integrations and automations act as service accounts, each holding roles like a person. An API key belongs to one service account, is stored only as a hash, can expire and can be revoked at any time, and what is done with it is recorded on the audit trail as that account. A webhook with a signing secret is checked by its signature and its time, so an old one cannot be replayed. Our services reach AWS through roles bound to each workload, and our build pipelines through short-lived OpenID Connect credentials, never through stored access keys. Your part: give each integration a service account of its own, with only the roles it needs, and name its owner in its description. |
| PRO-13.7 | Identity, credential and access management: Disable legacy authentication protocols or, where this is not feasible, restrict and monitor their use, apply compensating controls and establish a time-bound decommissioning plan. | In place | Shared | People sign in with a password and two-step sign-in, or through SAML or OpenID Connect single sign-on; integrations use API keys over HTTPS. No legacy protocol is offered. |
| PRO-13.8 | Identity, credential and access management: Ensure that user and non-person credentials are unique per system or account, particularly in high-privilege contexts. | In place | Customer | Integrations and automations act as service accounts, each holding roles like a person. An API key belongs to one service account, is stored only as a hash, can expire and can be revoked at any time, and what is done with it is recorded on the audit trail as that account. Your part: give each person an account of their own, and each integration an API key of its own. |
| PRO-12.1 | Least privilege access: Periodically review and update access privileges in alignment with current roles, duties and business requirements. | In place | Shared | Setup shows every role and what it allows, what any one person can do, and who can reach any one place (Roles, Explorer), and lists every change to roles (Roles, Activity). Your part: review roles, and what people can reach, at a set interval. |
| PRO-12.2 | Least privilege access: Restrict permissions to create, modify, or delete accounts and roles, or to access privileged functions or applications, to authorised administrative roles. | In place | Shared | What a person can see and do comes from their roles and from what is shared with them, and access to a place flows down to everything beneath it. Every operation in Pyron has a permission of its own, the permission engine's default answer is no, and only a role that holds the permission can add people, change roles or change the workspace's settings. Every change a person, an automation or the AI makes goes through the same path, which asks the permission engine before anything is written. Your part: give the permissions to add people and change roles only to your administrators. |
| PRO-12.3 | Least privilege access: Provision user, administrative and non-person accounts with only the minimum access and privileges required to perform defined operational functions. | In place | Shared | What a person can see and do comes from their roles and from what is shared with them, and access to a place flows down to everything beneath it. Every operation in Pyron has a permission of its own, the permission engine's default answer is no, and only a role that holds the permission can add people, change roles or change the workspace's settings. Your part: give each person and each service account only the roles they need. |
| PRO-05.1 | Secure administration: Ensure administrative activities against cloud management planes are performed only from managed, compliant, hardened devices. | Partial | Customer | A workspace admin can connect a SAML or OpenID Connect identity provider (Microsoft Entra ID, Okta, Google Workspace and others) in Setup, test it, then allow it beside passwords or make it required. Required switches password sign-in off for everyone, with no fallback. Pyron does not check the device a person signs in from. Your part: make single sign-on required, and enforce your device rules in your identity provider. |
| PRO-05.2 | Secure administration: Enforce explicit privilege activation before privileged actions are permitted, with approved and time-bound elevation limited to the functions required, and monitor privileged sessions and test response arrangements. | Partial | Shared | A workspace admin, or Support, can view Pyron as a particular person. A view-as session needs a reason, cannot change anything, ends within 60 minutes, and is recorded on the audit trail, naming who viewed and as whom. Techly's support engineers can sign in to any workspace to help, only through Techly's Google Workspace, which enforces 2-step verification, and a Support session lasts at most 8 hours and cannot be extended. What Support views and changes is recorded on the workspace's audit trail. A workspace cannot yet switch this access off. Our engineers sign in to AWS through IAM Identity Center, in sessions that expire, and the production database accepts only short-lived sign-in tokens, never a stored password. Administrator access is standing rather than raised for each task. A workspace admin's role is standing: Pyron has no time-bound elevation for a workspace's own people. Your part: keep administrator roles to the few people who need them. |
| PRO-05.3 | Secure administration: Record all administrative or management actions that modify cloud services, configurations or controls with the details of the identity, timestamp and target. | In place | Shared | Every change in a workspace is recorded in plain words, whoever made it: a person, an automation, the AI or Support. What people view is recorded too, and so are attempts the permission engine refuses. The trail is kept for 24 months: records are only ever added, never edited, and each is cryptographically linked to the one before it, so tampering would be evident. Activity on our AWS accounts is recorded by AWS CloudTrail into a separate archive account, where it is locked for 12 months. Your part: review the audit trail, or export it to your security system. |
| PRO-04.1 | Secure configuration management: Define approved configuration baselines for cloud services and tenant-level settings, informed by vendor and industry hardening guidance, that disable or remove unnecessary services, insecure settings and unsupported or weak protocols. | Partial | Pyron | Our cloud accounts, network edge and source control are defined in code, changed through pull requests, and scanned for insecure settings (Checkov) on every change. AWS Config and AWS Security Hub, which would check our cloud settings against best practice continuously, are not switched on. |
| PRO-04.2 | Secure configuration management: Deploy approved configuration baselines across cloud services, preferring policy-as-code and preventative guardrails that block non-compliant configurations at deployment. | In place | Pyron | Our cloud accounts, network edge and source control are defined in code, changed through pull requests, and scanned for insecure settings (Checkov) on every change. A policy pack refuses an infrastructure change that would make storage public, grant unbounded permissions or remove the database's deletion protection, before it reaches AWS; and organisation policies keep our accounts to approved regions and stop anyone switching off their logging. |
| PRO-04.3 | Secure configuration management: Detect and respond to configuration drift from approved configuration baselines using scheduled technical assessments and, where supported, automated monitoring, based on system criticality and change rate. | Partial | Pyron | Every night, each infrastructure stack is compared with its code, and a difference is fixed in code. AWS Config and AWS Security Hub, which would check our cloud settings against best practice continuously, are not switched on. |
| PRO-06.2 | Vulnerability management: Identify, prioritise and remediate vulnerabilities in customer-introduced applications, integrations and extensions within risk-based timeframes. | In place | Customer | Pages and automations run as programs in isolated sandboxes (Cloudflare Workers) with no network access of their own. A program reaches records only by asking Pyron, which checks permissions as it does for every other request. A shared page, automation or report changes only when someone with the right to publish it does. Earlier published versions are kept (the last 20 of a page or a report, every one of an automation) and can be restored. Your part: review what a page or an automation does before you publish it, and the connections you add. |
| PRO-06.3 | Vulnerability management: Apply security patches or updates to customer-managed components within defined risk-based timeframes, or automatically where impact is low. | Not applicable | Customer | Nothing in Pyron is software you manage: we update the service itself. |
| PRO-06.4 | Vulnerability management: Remediate or mitigate vulnerabilities exceeding defined risk thresholds within defined risk-based timeframes based on exploitation, exposure, criticality, impact and compensating controls and verify treatment effectiveness. | In place | Pyron | Every dependency is scanned for known vulnerabilities on each change and every day. A change that adds a high or critical advisory is blocked, and an accepted finding is recorded with its reason and an expiry, so it is looked at again. The Incident Management Policy sets a response time for each severity: a vulnerability with no sign it has been used is handled within the working week, and one that reaches customer data is an incident handled at once. |
| PRO-06.5 | Vulnerability management: Test security patches and updates before deployment and maintain tested rollback or recovery procedures to manage adverse operational impacts. | Partial | Pyron | Every change reaches production as a pull request, which merges only when its required checks pass: the test suites, a production build, an API contract check and a dependency scan. The team is small, and a second engineer's approval is not yet required. A fault in a release is fixed forward: there is no tested rollback. |
| PRO-07.1 | Trustworthy software: Restrict administrative and management tooling to approved software sets and executed only from authorised privileged systems. | Not applicable | Customer | Your organisation's own, with no part for Pyron. |
| PRO-07.2 | Trustworthy software: Regularly review proposed and approved software and application integrations in the organisational environment. | In place | Customer | Setup lists every person, guest, service account, API key, connection, stored login, automation, shared page and role in a workspace. Adding a connection to another service, a stored login or an API key is an operation of its own, which only a role that holds its permission can perform. Your part: review the connections and automations in Setup at a set interval. |
| PRO-07.3 | Trustworthy software: Permit only supported, verified and organisation-authorised software to execute, with exceptions minimised risk-accepted, time-bound, monitored and regularly reviewed. | In place | Shared | A shared page, automation or report changes only when someone with the right to publish it does. Earlier published versions are kept (the last 20 of a page or a report, every one of an automation) and can be restored. Pages and automations run as programs in isolated sandboxes (Cloudflare Workers) with no network access of their own. A program reaches records only by asking Pyron, which checks permissions as it does for every other request. Container images are built by our pipeline from base images pinned to an exact digest, with dependencies installed from locked versions, scanned when they are pushed, and stored under tags that cannot be overwritten. Your part: decide who may publish pages and automations. |
| PRO-08.1 | Cryptographic protection: Ensure data in transit and at rest is protected using best practice cryptographic algorithms and protocols, with weak or deprecated options disabled. | Partial | Shared | The database, its backups and stored files are encrypted with AES-256 under keys held in AWS Key Management Service, which rotate automatically; the secrets behind authenticator apps are encrypted a second time inside the database. Pyron is served only over HTTPS with TLS 1.2 or later, and tells browsers never to use plain HTTP; the database refuses an unencrypted connection, and file storage refuses an unencrypted request. Traffic between our own services inside the cluster is not encrypted. Your part: nothing to switch on, as encryption is always on. |
| PRO-08.2 | Cryptographic protection: Manage cryptographic keys securely throughout their lifecycle, including generation, validation, storage, rotations and revocation. | In place | Pyron | Encryption keys are created and held in AWS Key Management Service, never exported, and rotate automatically. |
| PRO-08.3 | Cryptographic protection: Retain customer control over the keys protecting the organisations most sensitive data, including the ability to revoke provider access. | Planned | Shared | A customer cannot hold or revoke the keys that protect its own data: Pyron holds them. |
| PRO-10.1 | Regular and proven backups: Back up settings, identities, policies, integrations, tenant configurations, and other important data to immutable storage on a defined schedule, implementing customer-controlled backup where provider arrangements are insufficient. | Partial | Shared | The database is backed up continuously and can be restored to any moment in the last 35 days. It is protected from deletion, a final snapshot is taken if it is ever deleted, and an earlier version of a replaced or deleted file is kept for 30 days. Backups are held in Melbourne only, in the same AWS account as production: there is no copy in a second region or account yet. Your part: if you need a copy under your own control, export your records. |
| PRO-10.2 | Regular and proven backups: Isolate backup repositories from production cloud environments through separate accounts, subscriptions or tenants with independent access controls, preventing unauthorised modification or deletion. | Planned | Customer | Backups are held in Melbourne only, in the same AWS account as production: there is no copy in a second region or account yet. Your part: keep your own exports apart from Pyron. |
| PRO-10.3 | Regular and proven backups: Conduct regular testing of backup data and restoration procedures to ensure that backups are reliable and capable of meeting defined recovery time objectives and recovery point objectives. | Planned | Customer | A full restore from backup has not yet been tested. No recovery time objective is set: no full restore has been tested yet. Your part: test that your own exports can be read back. |
| PRO-10.4 | Regular and proven backups: Establish recovery arrangements with the service provider, covering data loss, malicious deletion and tenant misconfiguration. | Partial | Shared | The database is backed up continuously and can be restored to any moment in the last 35 days. It is protected from deletion, a final snapshot is taken if it is ever deleted, and an earlier version of a replaced or deleted file is kept for 30 days. A shared page, automation or report changes only when someone with the right to publish it does. Earlier published versions are kept (the last 20 of a page or a report, every one of an automation) and can be restored. A full restore from backup has not yet been tested. Your part: agree with us how you would ask for a restore. |
| PRO-10.5 | Regular and proven backups: Vital cloud capabilities that require absolute availability for mission critical objectives are able to be quickly rebuilt on another provider if organisational needs demand. | Partial | Shared | People can export a table's records as a spreadsheet. When a subscription ends there is a 30-day export window, then deletion within 90 days; deleting a workspace removes its database schema, its files, its stored secrets and its single sign-on connection, and backups age out on their normal rotation. The production database runs in a single availability zone, with no standby, and we make no uptime commitment. Pyron itself cannot be rebuilt on another provider: what can move is your records, by export. Your part: keep an export of anything you would need to rebuild elsewhere. |
| PRO-18.1 | Network segmentation and segregation: Isolate workloads within network zones and limit lateral movement to explicitly approved pathways and service trust. | In place | Pyron | The database and the application have no public address: requests reach the application only through an encrypted Cloudflare tunnel, and network policies stop staging from ever reaching production. Each workspace's data lives in a database schema of its own, and every request is answered inside the schema of the workspace it was made to. Each workspace has its own environment in our authorisation service, and a sign-in names the workspace it was issued for, so no other workspace accepts it. The database server and the computing cluster are shared. Pages and automations run as programs in isolated sandboxes (Cloudflare Workers) with no network access of their own. A program reaches records only by asking Pyron, which checks permissions as it does for every other request. |
| PRO-09.1 | Content filtering: Block outbound network connections to known malicious or untrusted destinations. | In place | Pyron | Traffic leaving our servers passes through Cloudflare Gateway, which blocks known malware, phishing and command-and-control destinations and logs every destination, without decrypting traffic. If Gateway is unavailable, traffic continues without that filter rather than stopping: a risk we have accepted, so that an outage at the filter does not stop customers' automations. When Pyron fetches a web address for an automation or the assistant, it refuses private and internal addresses. |
| PRO-09.2 | Content filtering: Inspect and control outbound flows from cloud services to detect unauthorised transfer of sensitive or high-value data. | Partial | Traffic leaving our servers passes through Cloudflare Gateway, which blocks known malware, phishing and command-and-control destinations and logs every destination, without decrypting traffic. If Gateway is unavailable, traffic continues without that filter rather than stopping: a risk we have accepted, so that an outage at the filter does not stop customers' automations. Logins a workspace keeps in the Pyron Vault are stored encrypted, apart from the database. A hidden value is never shown to the AI, which reads only a hint of what it is for, and a value is only ever sent to the web addresses its login allows. Outbound traffic is not inspected for the data it carries. | |
| PRO-09.3 | Content filtering: Inspect inbound content from external or untrusted sources to prevent delivery of malicious or unsafe content. | In place | Pyron | Every uploaded file is scanned for malware before anyone can open it, and a file that holds malware is removed. Cloudflare's managed firewall rules, including the OWASP Core Ruleset, run in front of Pyron, and requests to its API are rate-limited there. |
| PRO-14.2 | Cyber security awareness training: Ensure all personnel receive cyber security awareness training, that is tailored to how they will interact with organisational systems in their assigned roles, before being granted access to organisational systems and data. | Not applicable | Customer | Your organisation's own, with no part for Pyron. |
| DET-01.2 | Centralised event logging: Enable provider audit logging at sufficient tiers and retention, and forward security-relevant logs and configuration changes to a central capability. | Partial | Shared | Every change in a workspace is recorded in plain words, whoever made it: a person, an automation, the AI or Support. What people view is recorded too, and so are attempts the permission engine refuses. The trail is kept for 24 months: records are only ever added, never edited, and each is cryptographically linked to the one before it, so tampering would be evident. People whose role allows it can export the audit trail, filtered or whole, as a spreadsheet or as a file for a security system (one event per line), and each export is itself recorded. There is no continuous feed to your security system yet: the trail is exported as a file. Your part: export the audit trail to your security system as often as you need. |
| DET-04.1 | Baselined high-risk access activities: Continuously monitor and analyse activity against established baselines to detect anomalous use of legitimate identities, services and software. | Planned | Pyron | Managed threat detection for our AWS accounts (Amazon GuardDuty), and detection of unusual sign-in patterns in Pyron, are not in place. |
| DET-02.3 | Cyber security event detection: Ensure event logs are normalised, time-synchronised and enriched to support correlation across cloud services and environments. | In place | Pyron | Logs, metrics and traces from every part of the service are collected through OpenTelemetry and go to Grafana Cloud in Australia, with credentials and what is said to and by the AI removed first. Alerts watch errors, response times, database capacity, background work, certificates and credentials, and each alert has a written runbook. |