ISO/IEC 27001
PezPC holds no ISO 27001 certificate and has never been audited against the standard. A number of its Annex A controls are nonetheless implemented, because they are good practice regardless of whether anyone is checking.
This walks the four Annex A themes of the 2022 revision and states where we actually stand on the controls that bear on a customer's information. It is not the full 93: controls that only make sense for a larger organisation, or that concern our internal operations rather than your data, are omitted rather than padded out with a claim. Nothing here should be read as certification. What certification would additionally require is a documented management system with defined scope, a risk treatment plan, management review, internal audit, and a Stage 1 and Stage 2 audit by an accredited body, none of which exist.
This expands one row of the standards table in the main privacy policy. The standard itself is published by its own authority: ISO catalogue.
All 93 Annex A controls, graded by us and not certified
No certificate, no external audit, and no independent review - A.5.35 is itself one of the gaps, and it is the control that would have to move first before any certification claim could begin. The pattern below is consistent and worth naming plainly: the technological controls are largely in place because they are decisions made in code, while the organisational, people and physical controls are largely absent because they are documented processes a very small team has not written down. That is a real shortfall rather than a paperwork quibble, and it is where the work would start.
13 in place 40 partial 36 not in place 4 not applicable
Organizational controls (A.5)
| A.5.1 | Policies for information security | Partial | Security practice is documented where it is customer-facing, which is what the privacy policy and these pages are. There is no internally maintained policy set that is approved, communicated and reviewed on a defined cycle. |
| A.5.2 | Information security roles and responsibilities | Not in place | Responsibility is held clearly in practice because the team is very small, but it is not defined or allocated in writing. |
| A.5.3 | Segregation of duties | Not in place | Not achievable at current headcount: the same people develop, release and administer production. Compensating controls are the audit trail and the published administration surface, not separation. |
| A.5.4 | Management responsibilities | Not in place | No documented requirement on personnel to apply security in accordance with established policies, because the policies in A.5.1 do not exist yet. |
| A.5.5 | Contact with authorities | Partial | The relevant authority is the OAIC and the path to it is understood and published for breach notification. Contact is not otherwise maintained. |
| A.5.6 | Contact with special interest groups | Not in place | No membership of security forums or professional associations is maintained. |
| A.5.7 | Threat intelligence | Not in place | Vendor and ecosystem advisories for shipped components are followed and acted on. There is no structured collection, analysis or contextualisation. |
| A.5.8 | Information security in project management | Partial | Security is considered when designing a feature and that reasoning is often recorded in the code and its history. It is not a defined project gate. |
| A.5.9 | Inventory of information and other associated assets | Partial | The information inventory is unusually good: every category held is enumerated publicly, table by table. Infrastructure asset inventory is informal. |
| A.5.10 | Acceptable use of information and other associated assets | Not in place | No documented acceptable use rules for staff handling customer information. |
| A.5.11 | Return of assets | Not in place | No documented process for return of assets on termination or change of role. |
| A.5.12 | Classification of information | Not in place | No classification scheme. In practice everything a customer gives us is treated as confidential and secrets are separated by encryption purpose, but that is a convention rather than a classified inventory. |
| A.5.13 | Labelling of information | Not in place | Follows A.5.12: with no classification scheme there is nothing to label to. |
| A.5.14 | Information transfer | Partial | Technical transfer is controlled: TLS on every external endpoint, and the recipients of any transfer are named publicly in the third-party table. There are no documented transfer rules or agreements covering staff behaviour. Third parties |
| A.5.15 | Access control | In place | Portal administrator access is a single explicit flag, granted deliberately and never inherited, and every screen it unlocks is published. The product ships a flat least-privilege permission model with no bypass. |
| A.5.16 | Identity management | In place | One account, one identity, one email address, with uniqueness enforced by the database. Deleted accounts are anonymised rather than removed so an identifier is never recycled onto a different person. |
| A.5.17 | Authentication information | In place | Passwords stored only as salted hashes and never written in recoverable form. Reset tokens stored as hashes, expiring, and recording the requesting address. Multi-factor one-time codes delivered out of band. |
| A.5.18 | Access rights | Partial | Rights are provisioned and removed deliberately, and deprovisioning on account deletion is immediate and complete. What is missing is periodic review: nothing forces a re-check that a standing grant is still warranted. |
| A.5.19 | Information security in supplier relationships | Partial | Every supplier touching customer information is named publicly with what it receives, which is more than most publish. We rely on their standard terms rather than negotiated requirements, and do not review them on a cycle. Third parties |
| A.5.20 | Addressing information security within supplier agreements | Not in place | We accept each supplier's standard published terms. No security requirements have been negotiated into any agreement. |
| A.5.21 | Managing information security in the information and communication technology (ICT) supply chain | Partial | The shipped dependency set is deliberately small and is tracked, with known-vulnerable versions pinned forward when advisories land. There is no formal supply chain risk process and no software bill of materials. |
| A.5.22 | Monitoring, review and change management of supplier services | Not in place | Supplier service changes are noticed when they break something, not through a defined monitoring or review process. |
| A.5.23 | Information security for use of cloud services | Partial | Exposure is deliberately minimal: no cloud hosting provider and no object storage in the path, with servers and database on hardware we operate in Australia. The cloud services in play are named. There is no cloud-specific policy or documented shared-responsibility model per provider. |
| A.5.24 | Information security incident management planning and preparation | Partial | Notifiable Data Breaches obligations are understood and the assessment and notification path is written down and published. There is no rehearsed incident response plan with defined roles. |
| A.5.25 | Assessment and decision on information security events | Not in place | No defined criteria or process for categorising an event and deciding whether it is an incident. |
| A.5.26 | Response to information security incidents | Not in place | No documented response procedures. Response today would be improvised, which is workable at this size and is still not what the control asks for. |
| A.5.27 | Learning from information security incidents | Not in place | No process to feed incident findings back into controls. |
| A.5.28 | Collection of evidence | Partial | The evidence exists and is unusually good: append-only logs of failed requests, sign-in attempts including failures, and every credential reveal. There is no documented procedure for identifying, collecting and preserving it. |
| A.5.29 | Information security during disruption | Not in place | No documented plan for maintaining security controls during a disruption. |
| A.5.30 | ICT readiness for business continuity | Not in place | No business continuity plan, no defined recovery time or recovery point objective, and no continuity testing. |
| A.5.31 | Legal, statutory, regulatory and contractual requirements | In place | The obligations binding us are identified explicitly rather than assumed: the Privacy Act and the APPs, the Notifiable Data Breaches scheme, the Spam Act, and the five-year tax record-keeping requirement. Each is stated with a link to its source. Standards |
| A.5.32 | Intellectual property rights | Partial | Third-party components are open-source with known licences, and the set is small and deliberate. There is no formal licence compliance review or bill of materials proving it. |
| A.5.33 | Protection of records | Partial | Records that must be retained are retained, and the tax retention requirement is identified. Protection is by ordinary access control rather than by a records management scheme with defined handling per record class. |
| A.5.34 | Privacy and protection of personal identifiable information (PII) | In place | The control the whole privacy policy exists to satisfy. Every category of personal information held is enumerated with its purpose, its recipients and its retention, and our position on all thirteen APPs is published. Australian Privacy Principles |
| A.5.35 | Independent review of information security | Not in place | No independent review has been carried out, internally or externally. This is the control that would have to move first for any certification claim. |
| A.5.36 | Compliance with policies, rules and standards for information security | Not in place | Nothing to check compliance against until A.5.1 exists, and no compliance checking is performed. |
| A.5.37 | Documented operating procedures | Partial | Deployment and installation are genuinely well documented, and the installers are scripted rather than tribal knowledge. Day-to-day operational procedures are not written down. |
People controls (A.6)
| A.6.1 | Screening | Not in place | No documented background verification process for personnel. |
| A.6.2 | Terms and conditions of employment | Partial | Engagement terms exist through the consultancy business. They do not set out information security responsibilities specific to PezNet operations. |
| A.6.3 | Information security awareness, education and training | Not in place | No training programme, no completion records, no refresher cycle. Claiming otherwise at this headcount would be inventing a process to fill a row. |
| A.6.4 | Disciplinary process | Not in place | No documented disciplinary process for information security violations. |
| A.6.5 | Responsibilities after termination or change of employment | Not in place | No documented continuing obligations, and no defined offboarding checklist. |
| A.6.6 | Confidentiality or non-disclosure agreements | Partial | Confidentiality obligations exist through the consultancy's engagement terms where staff are engaged under them. There is no separate, reviewed confidentiality regime specific to PezNet. |
| A.6.7 | Remote working | Not in place | Work is substantially remote and no remote working security policy exists. |
| A.6.8 | Information security event reporting | Partial | Customers have a working reporting channel: the in-app feedback route reaches us directly, and a security contact is published. There is no internal reporting procedure for staff. |
Physical controls (A.7)
| A.7.1 | Physical security perimeters | Partial | Our own servers sit on premises we control in Australia. The perimeter is not defined or documented to the standard's expectations. For a self-hosted install, the physical security of your server is entirely yours. |
| A.7.2 | Physical entry | Partial | Physical access is restricted in practice. There are no documented entry controls and no access records. |
| A.7.3 | Securing offices, rooms and facilities | Not in place | No documented physical security design for the areas housing infrastructure. |
| A.7.4 | Physical security monitoring | Not in place | No monitoring, alarm or logging of physical access to our infrastructure. |
| A.7.5 | Protecting against physical and environmental threats | Not in place | No documented assessment of fire, flood, or environmental risk to the infrastructure. |
| A.7.6 | Working in secure areas | Not applicable | No designated secure areas exist, so there are no working rules to define. This would change if a dedicated facility were established. |
| A.7.7 | Clear desk and clear screen | Not in place | No clear desk or clear screen policy. |
| A.7.8 | Equipment siting and protection | Partial | Equipment is sited sensibly and is not in a public area. Siting decisions are not documented against a risk assessment. |
| A.7.9 | Security of assets off-premises | Not in place | Laptops used off-premises are not covered by a documented control. |
| A.7.10 | Storage media | Not in place | No media handling procedure covering acquisition, use, transport or disposal. |
| A.7.11 | Supporting utilities | Partial | Power protection is in place. There is no documented assessment of utility failure or a tested response to it. |
| A.7.12 | Cabling security | Partial | Cabling is physically protected by virtue of the premises. Not documented. |
| A.7.13 | Equipment maintenance | Partial | Equipment is maintained as needed. There is no maintenance schedule or record. |
| A.7.14 | Secure disposal or re-use of equipment | Not in place | No documented procedure for verifying that storage media are sanitised before disposal or re-use. Worth noting that the product ships a data wipe record feature for exactly this purpose on customer assets, while we do not operate the equivalent process ourselves. |
Technological controls (A.8)
| A.8.1 | User end point devices | Not in place | No documented endpoint security standard, no central management, and no enforced disk encryption on developer machines. |
| A.8.2 | Privileged access rights | In place | Portal administrator rights are a single explicit flag, granted and revoked deliberately, never inherited. The product ships a flat least-privilege model with no super-user bypass, no impersonation and no vendor back door. |
| A.8.3 | Information access restriction | In place | Customer records are scoped to the account that owns them and every query filters on it. Cross-customer views exist only in administration screens, which are enumerated publicly. |
| A.8.4 | Access to source code | In place | Source lives in private repositories with access restricted to the development team, and all changes go through recorded commits. |
| A.8.5 | Secure authentication | In place | Multi-factor authentication is available on portal accounts. The product supports it, can delegate to an identity provider that enforces it, and requires a fresh step-up before any stored credential is revealed. |
| A.8.6 | Capacity management | Not in place | No capacity monitoring, forecasting or defined thresholds. |
| A.8.7 | Protection against malware | Partial | Uploaded feedback attachments are constrained by type and size, and both content type and extension must agree. There is no malware scanning of uploads and no endpoint anti-malware standard. |
| A.8.8 | Management of technical vulnerabilities | Partial | Dependencies are tracked and known-vulnerable versions pinned forward when advisories land. There is no scheduled scanning, no defined remediation window and no penetration test. |
| A.8.9 | Configuration management | Partial | Configuration is defined in version-controlled files and the installers are scripted, so deployments are repeatable. There is no baseline definition or drift detection. |
| A.8.10 | Information deletion | Partial | Account deletion is real and thorough for the categories it covers: installs, check-in history, licence tokens and reset history are destroyed and the account row anonymised. Nothing else expires on a schedule. How long we keep things |
| A.8.11 | Data masking | Partial | Secrets are masked to a last-four in the administration screens rather than displayed. There is no masking or pseudonymisation of personal data more broadly, and none in non-production use. |
| A.8.12 | Data leakage prevention | Not in place | No DLP tooling. The compensating design is that there is very little to leak: an email address, a display name and billing metadata, with none of a customer's operational records ever reaching us. |
| A.8.13 | Information backup | Partial | The database is backed up. Restore testing is not on a documented schedule and there is no defined recovery objective. |
| A.8.14 | Redundancy of information processing facilities | Not in place | No redundancy. A hardware failure means an outage, which is why the product is deliberately built to keep working through an offline grace window when it cannot reach the licence server. |
| A.8.15 | Logging | In place | Failed requests are recorded with correlation identifier, path, query, address, user agent and account. Sign-in attempts including failures, and every credential reveal, are recorded. Successful requests are deliberately not written to the database. |
| A.8.16 | Monitoring activities | Partial | Errors and delivery failures are surfaced in administration screens and reviewed. There is no alerting on anomalous authentication patterns, no correlation and no automated detection. |
| A.8.17 | Clock synchronization | Partial | Hosts synchronise time by default and all timestamps are stored in UTC, which is what makes logs correlatable. Not verified or monitored against an approved source. |
| A.8.18 | Use of privileged utility programs | Not in place | No restriction or logging of privileged utility program use on servers. |
| A.8.19 | Installation of software on operational systems | Partial | Application deployment is scripted and repeatable through the installer. There is no rule restricting what else may be installed on a server. |
| A.8.20 | Networks security | Partial | Services sit behind a reverse proxy with TLS termination and are not directly exposed. There is no documented network security standard. |
| A.8.21 | Security of network services | Partial | The security mechanisms of the services in use are known and deliberately chosen. They are not documented in a service agreement or reviewed. |
| A.8.22 | Segregation of networks | Not in place | No network segmentation between the application, database and administrative functions. |
| A.8.23 | Web filtering | Not applicable | No managed workstation fleet whose outbound browsing could be filtered. This would become applicable with centrally managed endpoints under A.8.1. |
| A.8.24 | Use of cryptography | In place | TLS on every external endpoint with certificates from Let's Encrypt. Passwords salted and hashed. Secrets encrypted at rest under keys held outside the database, each under its own protector purpose so a billing secret and a feedback token are not interchangeable. The product's vault uses AES-256-GCM envelope encryption with the master key on the file system, so a database dump alone decrypts nothing. |
| A.8.25 | Secure development life cycle | Partial | Development runs through source control with change history, a build pipeline and review before release. There is no documented secure development policy or defined security gate. |
| A.8.26 | Application security requirements | Partial | Security requirements are specified per feature in practice, and this repository carries a security checklist that every new surface is run against. It is a development convention rather than a controlled requirements process. |
| A.8.27 | Secure system architecture and engineering principles | Partial | Principles are applied and are unusually explicit: least privilege with no bypass, fail-closed permission checks, no ambient authority, and secrets separated by purpose. They are documented as engineering guidance rather than as an established, maintained architecture standard. |
| A.8.28 | Secure coding | In place | Parameterised queries throughout, antiforgery tokens on state-changing requests, output encoded rather than raw-rendered on any user-supplied content, webhook signatures verified against a shared secret, and outbound requests to admin-supplied targets passed through an SSRF guard. |
| A.8.29 | Security testing in development and acceptance | Partial | There is an automated test suite, including tests that specifically prove tenant isolation holds. There is no dedicated security test plan and no acceptance security criteria. |
| A.8.30 | Outsourced development | Not applicable | No development is outsourced. All code is written in-house. |
| A.8.31 | Separation of development, test and production environments | In place | Development runs against separate configuration and a separate licence endpoint, so developer activity cannot reach production customer records. |
| A.8.32 | Change management | Partial | Every change is committed with its reasoning and released deliberately. There is no formal approval step or documented per-change rollback plan. |
| A.8.33 | Test information | Partial | Development uses seeded and synthetic data rather than copies of production. This is a convention rather than a controlled and enforced rule. |
| A.8.34 | Protection of information systems during audit testing | Not applicable | No audit testing of operational systems has been performed, so there is nothing yet to control. This becomes applicable the moment A.5.35 moves. |