# AES Tech policy template pack Source: https://aestech.com.au/policy-templates/ Use these as starting points only. Adapt each policy to your real scope, systems, legal obligations, customer commitments and operating process. ## Contents 1. ISMS scope statement 2. Statement of Applicability (SoA) row 3. Risk register / risk assessment 4. Information security policy (outline) 5. Supplier security clause 6. Incident response plan (outline) 7. Cardholder data flow and inventory 8. PCI DSS scope definition 9. SAQ selection quick-guide 10. TPSP responsibility matrix 11. PCI incident response plan (outline) 12. Access control policy 13. Acceptable use policy 14. Information classification and handling policy 15. Supplier security policy 16. Incident response policy 17. Secure development policy 18. Backup and continuity policy 19. Endpoint and mobile device policy 20. Cryptography and key management policy 21. AI use and governance policy 22. Data retention and disposal policy 23. Backup policy 24. Vulnerability and patch management policy 25. Logging and monitoring policy 26. Business continuity and disaster recovery policy 27. Change management policy 28. Human resources security policy 29. Physical and environmental security policy 30. Data breach response policy 31. Mobile device and BYOD policy 32. Network security policy 33. Password and authentication policy 34. Malware protection policy 35. Security awareness and training policy 36. Cloud services and outsourcing policy 37. Asset management policy 38. ISMS internal audit procedure 39. Management review procedure 40. Nonconformity and corrective action procedure 41. Information risk management procedure 42. Remote and hybrid working policy 43. Email and communications security policy 44. Clear desk and clear screen policy 45. Information security roles and responsibilities ## ISMS scope statement Defines exactly what your ISMS covers. Auditors read this first. Frameworks: general ```text The Information Security Management System (ISMS) of [Company Pty Ltd] covers the provision of [product/service] to customers, including: - People: all staff and contractors of [teams/departments] - Processes: [e.g. software development, customer support, IT operations] - Technology: [e.g. the AWS production environment, corporate Google Workspace, employee endpoints] - Locations: [e.g. the Sydney office and all remote workers] Excluded from scope: [list exclusions and the justification]. Boundaries and interfaces with third parties: [e.g. AWS (IaaS), Stripe (payments)]. ``` ## Statement of Applicability (SoA) row One row per Annex A control. The central ISMS document. Frameworks: general ```text Columns: Control ID | Control name | Applicable (Y/N) | Justification | Implementation status | Reference Example: A.8.5 | Secure authentication | Y | MFA required for all access to production and email | Implemented | Okta policy POL-07 A.7.4 | Physical security monitoring | N | No company-controlled premises; fully remote | N/A | Remote Work Policy POL-12 ``` ## Risk register / risk assessment Records each risk, its rating, and how you will treat it. Frameworks: general ```text Columns: Risk ID | Asset | Threat | Vulnerability | Likelihood (1-5) | Impact (1-5) | Risk score | Owner | Treatment (Treat/Tolerate/Transfer/Terminate) | Controls | Residual score | Review date Example: R-014 | Customer database | Credential theft | No MFA on admin | 4 | 5 | 20 | CTO | Treat | A.8.5 MFA, A.8.2 privileged access | 6 | 2026-09-30 ``` ## Information security policy (outline) The top-level policy. Keep topic policies separate and reference them. Frameworks: general ```text 1. Purpose and scope 2. Information security objectives 3. Roles and responsibilities (incl. management commitment) 4. Risk management approach 5. Policy areas (reference): Access Control, Acceptable Use, Cryptography, Supplier Security, Incident Response, Business Continuity, Secure Development 6. Legal and contractual obligations 7. Compliance, exceptions and disciplinary process 8. Review: at least annually, owned by [role] Approved by: [name/role] Version: [x.y] Date: [date] ``` ## Supplier security clause Drop into vendor agreements (maps to A.5.20). Frameworks: general ```text The Supplier shall: (a) implement and maintain information security controls appropriate to the data processed, consistent with recognised standards such as ISO/IEC 27001; (b) notify [Company] of any security incident affecting [Company] data without undue delay and within [24/48] hours; (c) permit reasonable review of its security posture on request; (d) ensure subcontractors are bound by equivalent obligations; and (e) return or securely delete [Company] data on termination. ``` ## Incident response plan (outline) Maps to A.5.24 to A.5.28. Frameworks: general ```text 1. Purpose and scope 2. Severity levels (SEV1-SEV4) and examples 3. Roles: Incident Manager, Comms Lead, Technical Lead, Exec sponsor 4. Phases: Detect -> Triage -> Contain -> Eradicate -> Recover -> Review 5. Reporting channel: [how staff report], 24/7 contact: [details] 6. External contacts: regulators, law enforcement, key customers, cyber insurer 7. Evidence handling and chain of custody 8. Communication templates (internal, customer, regulator) 9. Post-incident review: within [5] business days, actions tracked to closure 10. Test: tabletop exercise at least annually ``` ## Cardholder data flow and inventory Find and document every place card data lives or moves. Shrinking this shrinks scope. Frameworks: general ```text For each flow: Source -> Transport -> Process -> Store? Columns: Flow ID | Channel (web/phone/POS) | Data elements (PAN, expiry, CVV) | Systems touched | Encrypted? | Stored? (where/how long) | Owner Example: F-01 | E-commerce checkout | PAN, expiry | Browser -> Stripe.js -> Gateway | TLS 1.3 | No (tokenised) | Payments lead F-02 | Phone orders | PAN read aloud | Agent -> virtual terminal | TLS | No | Support lead ``` ## PCI DSS scope definition Document and validate scope at least annually (req 12.5). Frameworks: general ```text 1. Cardholder data environment (CDE): [systems that store/process/transmit CHD] 2. Connected-to / security-impacting systems: [e.g. jump hosts, logging, IdP] 3. Out of scope (and why): [segmented systems with no CHD access] 4. Network segmentation in place: [yes/no, how verified] 5. Third-party service providers in scope: [list + what they handle] 6. Merchant level: [1-4] SAQ type or ROC: [type] Reviewed by: [name] Date: [date] Next review: [date] ``` ## SAQ selection quick-guide Pick the right Self-Assessment Questionnaire for how you take payments. Frameworks: general ```text SAQ A Card-not-present, payment fully outsourced to a compliant third party (e.g. hosted/redirect or iframe). Smallest scope. SAQ A-EP E-commerce, payment processing outsourced but your site can affect the payment (e.g. JavaScript on your page). SAQ B Imprint machines or standalone dial-out terminals. No electronic storage. SAQ B-IP Standalone, IP-connected payment terminals. No electronic storage. SAQ C-VT Web-based virtual terminal, one device, no storage. SAQ C Payment application connected to the internet, no storage. SAQ P2PE Hardware payment terminals in a validated P2PE solution. No storage. SAQ D Everything else, including all service providers. Largest scope. Confirm your eligibility and level with your acquiring bank. ``` ## TPSP responsibility matrix Split each requirement between you and each provider (req 12.8/12.9). Frameworks: general ```text Columns: PCI requirement | Your responsibility | TPSP responsibility | Evidence held Example: Req 3 (stored data) | We store no CHD | Stripe stores/tokenises CHD | Stripe AOC on file Req 9 (physical) | Office + endpoints | AWS data-centre physical security | AWS AOC / shared responsibility Req 11 (testing) | App pen test, internal scans | Provider infrastructure testing | Pen test report; provider AOC ``` ## PCI incident response plan (outline) Required by req 12.10; must cover suspected card-data compromise. Frameworks: general ```text 1. Roles and 24/7 contacts 2. Severity and what counts as a suspected card-data compromise 3. Immediate actions: contain, preserve evidence, do not wipe 4. Who to notify and when: acquiring bank, card brands, forensic (PFI) if required, regulators 5. Containment and recovery steps 6. Communication templates 7. Post-incident review and control updates 8. Test at least annually ``` ## Access control policy Use for ISO 27001 A.5.15, A.5.16, A.5.17, A.5.18, A.8.2, SOC 2 Security, and PCI DSS requirements 7 and 8. Frameworks: ISO 27001, SOC 2, PCI DSS ```text 1. Purpose This policy defines how access to company systems, data, facilities and administrative functions is requested, approved, provisioned, reviewed and removed. 2. Scope This policy applies to all employees, contractors, service accounts, administrator accounts, production systems, business systems and third-party access. 3. Principles - Access is granted only for a documented business need. - Least privilege and need-to-know apply by default. - Shared user accounts are prohibited unless explicitly approved and monitored. - Privileged access requires separate approval and stronger monitoring. - MFA is required for email, identity, cloud, production, code, finance and admin systems. 4. Process - Access requests must be submitted in [ticketing system]. - The system owner approves access before provisioning. - IT or the system administrator provisions access according to the approved role. - Access is removed within [x] hours of termination and adjusted on role change. - Privileged access is reviewed at least quarterly. 5. Evidence Keep access request tickets, approval records, provisioning logs, access review sign-offs, offboarding records and exception approvals. Owner: [role] Review cadence: at least annually and after major system or role changes. ``` ## Acceptable use policy Use for ISO 27001 A.5.10, A.6.3, A.6.4, endpoint controls, remote work, and SOC 2 Security awareness. Frameworks: ISO 27001, SOC 2 ```text 1. Purpose This policy defines acceptable use of company information, devices, networks, SaaS tools, AI tools and communication systems. 2. User responsibilities Users must: - Protect company and customer information according to its classification. - Use approved systems for company work. - Lock screens when unattended. - Report suspected security events immediately. - Use company-approved AI tools only for permitted data types. - Follow password, MFA and device security requirements. 3. Prohibited activity Users must not: - Share credentials. - Store confidential data in unapproved tools. - Bypass security controls. - Install unapproved software on managed devices. - Upload customer, source-code or confidential information to unapproved AI systems. 4. Monitoring and enforcement The company may monitor company systems to protect security, meet legal obligations and investigate misuse. Violations may lead to access removal or disciplinary action. Evidence: signed acknowledgements, training completion, exception approvals, monitoring records and incident tickets. ``` ## Information classification and handling policy Use for ISO 27001 A.5.12, A.5.13, A.5.14, privacy, SOC 2 Confidentiality, and data handling controls. Frameworks: ISO 27001, SOC 2, PCI DSS ```text 1. Purpose This policy defines how information is classified, labelled, stored, transferred, retained and disposed of. 2. Classification levels - Public: approved for public release. - Internal: business information for employees and contractors. - Confidential: customer, employee, financial, security or commercial information. - Restricted: highly sensitive data such as credentials, production secrets, regulated data or security evidence. 3. Handling rules - Confidential and Restricted data must be stored only in approved systems. - External transfer requires approved channels and encryption where appropriate. - Restricted data must not be used in test, demo or AI tools unless approved and masked. - Records must be retained according to the retention schedule. - Data past its retention period must be deleted or anonymised. 4. Evidence Keep data inventories, transfer approvals, DLP alerts, retention schedules, deletion records, data processing records and exceptions. Owner: [role] Review cadence: annually and after material data-flow changes. ``` ## Supplier security policy Use for ISO 27001 A.5.19 to A.5.23, SOC 2 vendor management, cloud services, and AI supplier reviews. Frameworks: ISO 27001, SOC 2, ISO 42001 ```text 1. Purpose This policy defines how suppliers are assessed, approved, monitored and offboarded when they can affect company information, customer data or critical services. 2. Supplier risk tiers - Critical: stores or processes confidential data, affects production, security, availability or regulated obligations. - Standard: supports business processes but has limited data or system access. - Low: no access to confidential data or critical systems. 3. Due diligence Before approval, critical suppliers must be reviewed for security posture, privacy, data location, subcontractors, incident notification, continuity, certifications and contractual terms. 4. Ongoing review Critical suppliers are reviewed at least annually and after major scope, product, location, subprocessor or incident changes. 5. Evidence Keep supplier register, risk tier, review records, security reports, contracts, data processing terms, offboarding records and exception approvals. ``` ## Incident response policy Use for ISO 27001 A.5.24 to A.5.28, SOC 2 incident response, PCI DSS 12.10, and security event handling. Frameworks: ISO 27001, SOC 2, PCI DSS ```text 1. Purpose This policy defines how security events and incidents are reported, assessed, contained, investigated, communicated and reviewed. 2. Severity levels - SEV1: confirmed breach, active compromise, material customer impact or legal notification likely. - SEV2: serious security event requiring urgent investigation. - SEV3: contained event or control failure with limited impact. - SEV4: low-risk event, alert or near miss. 3. Process - Detect and report through [channel]. - Triage and classify severity. - Contain affected accounts, devices, systems or integrations. - Preserve evidence before changes are made. - Eradicate root cause and recover service. - Communicate to internal and external stakeholders as required. - Complete post-incident review within [x] business days. 4. Evidence Keep incident tickets, timeline, affected assets, decisions, communications, evidence chain, root cause, corrective actions and closure approval. ``` ## Secure development policy Use for ISO 27001 A.8.25 to A.8.32, source code controls, change management, and SOC 2 change controls. Frameworks: ISO 27001, SOC 2 ```text 1. Purpose This policy defines how software and system changes are designed, built, tested, approved, released and monitored securely. 2. Requirements - Security requirements must be considered during design. - Source code repositories require MFA, least privilege, branch protection and review. - Changes must be tracked in tickets or pull requests. - Code review is required before merge. - Security testing must include dependency scanning and appropriate static or dynamic testing. - Production releases require approval and rollback planning. - Production, test and development environments must be separated. - Production data must not be copied into test environments unless approved and masked. 3. Evidence Keep design reviews, tickets, pull requests, approvals, test results, release records, rollback plans, vulnerability remediation records and exceptions. ``` ## Backup and continuity policy Use for ISO 27001 A.5.29, A.5.30, A.8.13, A.8.14, SOC 2 Availability, and resilience controls. Frameworks: ISO 27001, SOC 2 ```text 1. Purpose This policy defines how critical systems and information are backed up, restored and kept available during disruption. 2. Requirements - Critical systems must have defined recovery time objectives and recovery point objectives. - Backups must be protected against unauthorised access and deletion. - Backup coverage must be monitored. - Restore tests must be performed at least annually for critical systems. - Continuity plans must include security responsibilities during disruption. - Failover or redundancy must match the availability commitment made to customers. 3. Evidence Keep backup job reports, restore test records, recovery objectives, continuity exercises, failover tests, incident records and corrective actions. ``` ## Endpoint and mobile device policy Use for ISO 27001 A.6.7, A.7.9, A.8.1, malware protection, remote work, and SOC 2 endpoint controls. Frameworks: ISO 27001, SOC 2 ```text 1. Purpose This policy defines baseline security requirements for laptops, mobile devices and remote work. 2. Requirements - Company devices must be enrolled in device management where practical. - Disk encryption, screen lock and supported operating systems are required. - Endpoint protection or malware protection must be enabled. - Lost or stolen devices must be reported immediately. - Confidential information must not be stored on unmanaged removable media. - Remote work must use approved networks, MFA and secure storage practices. 3. Evidence Keep device inventory, MDM compliance reports, endpoint protection status, encryption status, exception approvals and lost-device incident records. ``` ## Cryptography and key management policy Use for ISO 27001 A.8.24, secure authentication, encryption, SOC 2 Security, and PCI DSS encryption requirements. Frameworks: ISO 27001, SOC 2, PCI DSS ```text 1. Purpose This policy defines how encryption and cryptographic keys are selected, used, protected, rotated and retired. 2. Requirements - Use TLS for data in transit where confidential or customer data is transmitted. - Encrypt confidential and restricted data at rest where supported. - Store secrets in approved secret managers, not source code or documents. - Limit access to keys to authorised roles. - Rotate keys after compromise, staff changes affecting key access, or according to system requirements. - Retire and destroy keys when no longer needed. 3. Evidence Keep encryption configuration, key access records, rotation logs, secret scanning results, exceptions and incident records. ``` ## AI use and governance policy Use for ISO 42001, AI governance, employee AI use, data handling, human review, and AI supplier risk. Frameworks: ISO 42001, ISO 27001, SOC 2 ```text 1. Purpose This policy defines how AI systems and AI tools are approved, used, monitored and reviewed. 2. Requirements - Keep an inventory of AI systems and approved AI tools. - Classify each AI system by purpose, data used, owner, affected stakeholders and risk tier. - Prohibit uploading confidential, restricted, customer, source-code or regulated data to unapproved AI tools. - Require human review for AI outputs used in consequential decisions, customer commitments, legal, security or financial workflows. - Review AI suppliers for data use, model training terms, confidentiality, security and change notification. - Record incidents, unsafe outputs, hallucination patterns, complaints, drift and material changes. 3. Evidence Keep AI inventory, AI impact assessments, supplier reviews, approved tool list, human review records, incidents, exceptions and management reviews. ``` ## Data retention and disposal policy Use for ISO 27001 A.5.33, A.5.34, A.8.10, SOC 2 Confidentiality and Privacy, and PCI DSS requirement 3. Frameworks: ISO 27001, SOC 2, PCI DSS ```text 1. Purpose This policy defines how long records and data are kept, how they are securely disposed of when no longer required, and how the company meets legal, contractual and regulatory retention obligations. It limits the volume of data held to what is necessary, reducing risk and audit scope. 2. Scope This policy applies to all company and customer information in any format, including production databases, backups, file storage, email, paper records, removable media and data held by suppliers on the company behalf. It applies to all employees, contractors and service accounts. 3. Policy statements - Every category of data must have a defined retention period recorded in the retention schedule. - Data must not be kept longer than the retention period unless there is a legal hold, active investigation or documented business need approved by the data owner. - Personal and regulated data must be retained only for as long as the lawful purpose requires. - Cardholder data must be kept to the minimum required and deleted when no longer needed for a documented legal, regulatory or business reason. - When a retention period ends, data must be deleted, anonymised or destroyed using approved methods. - Electronic media must be sanitised or destroyed before reuse, return or disposal so that data cannot be recovered. - Paper records must be shredded or disposed of through an approved secure destruction service. - Suppliers holding company data must delete or return it on contract termination and on request. - Legal holds override scheduled deletion until the hold is formally released. 4. Roles and responsibilities - The [Data Protection Lead] owns the retention schedule and approves changes. - Data owners confirm retention periods for their data categories and authorise exceptions. - IT and system administrators implement deletion and media sanitisation. - Legal advises on retention obligations and issues or releases legal holds. - All staff follow the schedule and do not retain copies of data outside approved systems. 5. Procedures - Maintain a retention schedule listing data category, owner, system, retention period, legal basis and disposal method. - Review the retention schedule at least annually and after legal or product changes. - Run scheduled or periodic deletion jobs for data that has reached end of retention. - Sanitise media using cryptographic erasure, secure wipe or physical destruction, and record the method. - Issue a certificate of destruction for physical media and bulk destruction events. - Apply and track legal holds through [legal hold register]. 6. Evidence and records Keep the retention schedule, deletion job logs, media sanitisation and destruction records, certificates of destruction, legal hold register, supplier deletion confirmations and exception approvals. 7. Review cadence This policy is reviewed at least annually and after material changes to legal, regulatory or contractual retention obligations. Owner: [role] Version: [x.y] Approved by: [name/role] Date: [date] ``` ## Backup policy Use for ISO 27001 A.8.13, A.8.14, SOC 2 Availability, and PCI DSS requirement 12 resilience expectations. Frameworks: ISO 27001, SOC 2 ```text 1. Purpose This policy defines how company and customer data is backed up, protected, tested and restored so that information can be recovered after loss, corruption, ransomware or system failure. 2. Scope This policy applies to all critical systems, production databases, configuration data, source code, and any information whose loss would materially affect the business or customers. It applies to backups stored on company infrastructure and with cloud or third-party providers. 3. Policy statements - Each critical system must have a defined backup frequency aligned to its recovery point objective. - Each critical system must have a defined recovery time objective. - Backups must be encrypted at rest and in transit. - At least one backup copy must be kept in a separate location or account from the primary system. - Backups must be protected against unauthorised access, modification and deletion, including protection against ransomware such as immutable or write-once storage where available. - Backup success and failure must be monitored, and failures must be investigated and resolved. - Restore tests must be performed at least annually for each critical system, and results recorded. - Backup retention must align with the data retention schedule and any regulatory requirements. 4. Roles and responsibilities - The [IT Manager] owns the backup programme and approves backup configurations. - System owners define recovery point and recovery time objectives for their systems. - IT and system administrators configure, monitor and test backups. - The [Security Lead] reviews backup protection controls and restore test results. 5. Procedures - Maintain a backup register listing system, data, frequency, retention, location and owner. - Configure automated backups for all in-scope systems. - Monitor backup jobs daily and alert on failures. - Perform and document a restore test for each critical system at least annually. - Review backup encryption, access controls and immutability settings at least annually. 6. Evidence and records Keep the backup register, backup job reports, restore test records, recovery objective definitions, encryption and access configuration, immutability settings and exception approvals. 7. Review cadence This policy is reviewed at least annually and after major changes to systems, providers or recovery objectives. Owner: [role] Version: [x.y] Approved by: [name/role] Date: [date] ``` ## Vulnerability and patch management policy Use for ISO 27001 A.8.8, A.8.19, A.8.32, SOC 2 Security, and PCI DSS requirements 6 and 11. Frameworks: ISO 27001, SOC 2, PCI DSS ```text 1. Purpose This policy defines how technical vulnerabilities are identified, assessed, prioritised and remediated, and how security patches are applied across company systems, in order to reduce the risk of exploitation. 2. Scope This policy applies to all production and corporate systems, servers, endpoints, cloud services, containers, network devices, applications and third-party software components used by the company. 3. Policy statements - Vulnerability scanning must be performed regularly on internal and external systems. - Discovered vulnerabilities must be assigned a severity using a recognised scoring method such as CVSS. - Remediation timeframes apply from the date a vulnerability is confirmed: - Critical: within [7] days. - High: within [30] days. - Medium: within [90] days. - Low: at the next scheduled maintenance. - Security patches must be tested where practical and applied within the remediation timeframe for their severity. - Where a vulnerability cannot be remediated in time, a compensating control and a documented, time-bound exception must be approved. - Internet-facing systems and systems handling regulated data are prioritised. - Penetration testing must be performed at least annually and after significant changes. - Software components and dependencies must be tracked, and end-of-life software must be replaced or isolated. 4. Roles and responsibilities - The [Security Lead] owns the vulnerability management programme and approves exceptions. - System and application owners remediate vulnerabilities in their systems within the required timeframe. - IT applies operating system and infrastructure patches. - Developers update vulnerable application dependencies. 5. Procedures - Run authenticated vulnerability scans on a [weekly or monthly] cadence and external scans regularly. - Triage findings, deduplicate, assign severity and create remediation tickets. - Track remediation to closure against the required timeframes. - Record and review exceptions with compensating controls. - Commission annual penetration testing and remediate findings. 6. Evidence and records Keep scan reports, remediation tickets and timestamps, patch records, penetration test reports, exception approvals, software inventory and end-of-life tracking. 7. Review cadence This policy is reviewed at least annually and after significant changes to the environment or threat landscape. Owner: [role] Version: [x.y] Approved by: [name/role] Date: [date] ``` ## Logging and monitoring policy Use for ISO 27001 A.8.15, A.8.16, A.8.17, SOC 2 Security, and PCI DSS requirements 10 and 11. Frameworks: ISO 27001, SOC 2, PCI DSS ```text 1. Purpose This policy defines how events on company systems are logged, retained, protected and monitored so that security events can be detected, investigated and used as evidence. 2. Scope This policy applies to all production systems, cloud platforms, identity and access systems, network devices, applications, security tools and administrative activity. It applies to all employees, contractors and service accounts whose actions are recorded. 3. Policy statements - Security relevant events must be logged, including authentication, authorisation changes, privileged actions, access to sensitive data, configuration changes and security tool alerts. - Logs must include enough detail to answer who did what, when, from where and the outcome. - Clocks across systems must be synchronised to a reliable time source. - Logs must be protected against unauthorised access, modification and deletion. - Logs must be retained for at least [12] months, with at least [3] months immediately available, or longer where regulation requires. - Security alerts must be reviewed and triaged, and confirmed events must follow the incident response process. - Monitoring must include alerting for suspicious activity such as repeated failed logins, privilege escalation and unusual data access. 4. Roles and responsibilities - The [Security Lead] owns the logging and monitoring programme and defines required log sources. - IT and system owners ensure their systems forward required logs. - The [Security Operations] function or designated staff review and triage alerts. - The [Incident Response] team handles confirmed security events. 5. Procedures - Maintain a list of in-scope log sources and required event types. - Forward logs to a central, access-controlled logging platform. - Configure time synchronisation across systems. - Define and tune alert rules for high-risk activity. - Review alerts on a defined cadence and record actions taken. - Periodically verify that critical log sources are still reporting. 6. Evidence and records Keep the log source inventory, logging configuration, retention settings, alert rules, alert review records, time synchronisation configuration and access controls on the logging platform. 7. Review cadence This policy is reviewed at least annually and after material changes to systems or threats. Owner: [role] Version: [x.y] Approved by: [name/role] Date: [date] ``` ## Business continuity and disaster recovery policy Use for ISO 27001 A.5.29, A.5.30, A.5.7, SOC 2 Availability, and resilience and recovery requirements. Frameworks: ISO 27001, SOC 2 ```text 1. Purpose This policy defines how the company maintains and recovers critical operations during and after a disruptive event, and how information security is preserved throughout. It establishes recovery objectives and the planning, testing and review needed to meet them. 2. Scope This policy applies to all critical business processes, supporting systems, people and facilities. It covers events such as major system outages, supplier failure, cyber incidents, loss of premises and loss of key staff. 3. Policy statements - Critical business processes must be identified through a business impact analysis and reviewed at least annually. - Each critical process must have a recovery time objective and, where data is involved, a recovery point objective. - Business continuity and disaster recovery plans must be documented, accessible during a disruption and assigned to named owners. - Information security controls must remain in force during disruption and recovery, including access control, logging and approvals. - Continuity and recovery plans must be tested at least annually, and results must drive improvements. - Key dependencies on suppliers and cloud providers must be assessed for continuity. - Crisis communication arrangements must cover staff, customers, regulators and other stakeholders. 4. Roles and responsibilities - Executive management sponsors the programme and approves recovery objectives. - The [Continuity Lead] maintains the business impact analysis and coordinates plans and tests. - Process and system owners maintain recovery procedures for their areas. - The [Incident Response] team coordinates with continuity activities during major events. 5. Procedures - Conduct and maintain a business impact analysis of critical processes and dependencies. - Document continuity plans and technical disaster recovery procedures for critical systems. - Define activation criteria, recovery teams and escalation paths. - Run continuity and recovery exercises at least annually, including at least one realistic scenario test. - Record lessons learned and track corrective actions to closure. 6. Evidence and records Keep the business impact analysis, recovery objectives, continuity and recovery plans, exercise records, test results, corrective actions and communication templates. 7. Review cadence This policy and the supporting plans are reviewed at least annually and after major incidents or significant business change. Owner: [role] Version: [x.y] Approved by: [name/role] Date: [date] ``` ## Change management policy Use for ISO 27001 A.8.32, A.8.9, SOC 2 change management criteria, and PCI DSS requirement 6 change controls. Frameworks: ISO 27001, SOC 2, PCI DSS ```text 1. Purpose This policy defines how changes to production systems, applications, infrastructure and configurations are requested, assessed, approved, tested, implemented and reviewed, so that changes do not introduce security or availability risk. 2. Scope This policy applies to all changes to production and security-relevant systems, including code deployments, infrastructure changes, configuration changes, database changes and changes to security controls. It applies to all employees and contractors who make such changes. 3. Policy statements - All changes to production must be recorded in a ticket or pull request before implementation. - Changes must describe the reason, the affected systems, the risk and the rollback plan. - Changes must be reviewed and approved by an authorised person other than the sole implementer, except for pre-approved standard changes. - Changes must be tested before release where practical. - Production, test and development environments must be kept separate. - Emergency changes may bypass normal lead time but must still be recorded, approved as soon as practical and reviewed afterwards. - Significant changes must be assessed for their effect on security controls and compliance scope. - Changes affecting customers or availability must include a communication and rollback plan. 4. Roles and responsibilities - The [Engineering Lead] owns the change process and the definition of standard changes. - Change requesters document and propose changes. - Approvers review risk and authorise changes. - Implementers carry out changes and confirm success or trigger rollback. 5. Procedures - Raise a change record with description, risk, test evidence and rollback plan. - Obtain the required review and approval before deployment. - Deploy through the approved pipeline and verify the outcome. - For emergency changes, record the change, gain expedited approval and complete a post-change review. - Maintain a list of pre-approved standard changes and review it periodically. 6. Evidence and records Keep change tickets and pull requests, approvals, test evidence, deployment records, rollback plans, emergency change reviews and the standard change list. 7. Review cadence This policy is reviewed at least annually and after major changes to the deployment process. Owner: [role] Version: [x.y] Approved by: [name/role] Date: [date] ``` ## Human resources security policy Use for ISO 27001 A.6.1 to A.6.6, A.6.8, SOC 2 Security, and personnel security controls. Frameworks: ISO 27001, SOC 2 ```text 1. Purpose This policy defines the security responsibilities and controls that apply to people before, during and after employment or engagement with the company, so that staff understand and meet their information security obligations. 2. Scope This policy applies to all employees and contractors throughout their relationship with the company, from recruitment to termination, including changes of role. 3. Policy statements - Background and identity verification appropriate to the role and to legal limits must be completed before access to sensitive systems is granted. - Employment and contractor agreements must include information security and confidentiality obligations. - New starters must receive security awareness training before or shortly after gaining access, and refresher training at least annually. - Access must be granted according to role and the access control policy, and adjusted promptly on role change. - On termination or end of engagement, access must be revoked within [x] hours and company assets must be returned. - A disciplinary process must apply to breaches of security policy, applied consistently and fairly. - Confidentiality obligations continue after employment ends where appropriate. 4. Roles and responsibilities - [HR] manages screening, agreements, onboarding and offboarding administration. - Hiring managers define role requirements and approve access needs. - IT provisions and revokes access in line with HR triggers. - The [Security Lead] owns security awareness training and the security elements of the disciplinary process. 5. Procedures - Complete pre-employment screening proportionate to the role. - Issue agreements that include security and confidentiality terms. - Run onboarding that includes security training and acknowledgement of key policies. - Trigger access changes for joiners, movers and leavers through a defined workflow. - Recover assets and confirm access removal at offboarding. - Track training completion and follow up non-completion. 6. Evidence and records Keep screening records, signed agreements and acknowledgements, training completion records, joiner, mover and leaver tickets, asset return records and disciplinary records where applicable. 7. Review cadence This policy is reviewed at least annually and after changes to legal or regulatory requirements. Owner: [role] Version: [x.y] Approved by: [name/role] Date: [date] ``` ## Physical and environmental security policy Use for ISO 27001 A.7.1 to A.7.14, SOC 2 Security, and PCI DSS requirement 9 physical access controls. Frameworks: ISO 27001, SOC 2, PCI DSS ```text 1. Purpose This policy defines how company facilities, equipment and physical media are protected against unauthorised access, damage, theft and environmental threats. 2. Scope This policy applies to all company premises, secure areas, equipment, media and the facilities of providers that host company systems. Where the company is fully remote, the requirements apply to data centre and cloud provider facilities and to home working arrangements. 3. Policy statements - Access to offices and secure areas must be restricted to authorised people and controlled by suitable measures such as locks, access cards or reception controls. - Visitors must be identified, recorded and supervised in sensitive areas. - Physical access rights must be reviewed periodically and revoked promptly when no longer needed. - Equipment must be protected from theft, damage and unauthorised use, and must not be left unattended in insecure locations. - A clear desk and clear screen practice applies to confidential information. - Media and equipment containing data must be securely sanitised or destroyed before disposal or reuse. - Environmental controls such as power protection, fire detection and suitable cooling must protect critical equipment, primarily through the hosting provider. - Where systems are hosted with cloud or data centre providers, physical security must be confirmed through provider attestations. 4. Roles and responsibilities - The [Facilities or Office Manager] manages premises access and visitor controls. - IT manages equipment, media disposal and asset tracking. - The [Security Lead] reviews physical controls and provider attestations. - All staff follow clear desk, clear screen and visitor handling rules. 5. Procedures - Maintain an access list for offices and secure areas and review it periodically. - Record and supervise visitors. - Track equipment and media as assets and record secure disposal. - Obtain and review physical security attestations from hosting providers at least annually. - Define home working security expectations for remote staff. 6. Evidence and records Keep access lists and reviews, visitor logs, asset and media inventories, secure disposal records, provider attestations and exception approvals. 7. Review cadence This policy is reviewed at least annually and after changes to premises or hosting arrangements. Owner: [role] Version: [x.y] Approved by: [name/role] Date: [date] ``` ## Data breach response policy Use for ISO 27001 A.5.24 to A.5.28, SOC 2 incident handling, privacy notification, and PCI DSS requirement 12.10. Frameworks: ISO 27001, SOC 2, PCI DSS ```text 1. Purpose This policy defines how the company responds to a suspected or confirmed data breach involving personal, customer, cardholder or other sensitive data, including assessment, containment, notification and review. It complements the incident response policy with breach-specific notification duties. 2. Scope This policy applies to any event that may have resulted in unauthorised access to, disclosure of, loss of or alteration of personal or sensitive data, whether caused internally, by a supplier or by an external attacker. 3. Policy statements - Any suspected data breach must be reported immediately through the incident channel. - The company must assess whether personal or sensitive data was involved and the likely harm to affected individuals. - Containment must take priority, while preserving evidence for investigation. - The company must determine its notification obligations to regulators, affected individuals, customers, card brands and acquiring banks, and the applicable timeframes. - Where notification to a regulator is required, it must be made within the legally required timeframe, for example without undue delay and within [72] hours of becoming aware where that applies. - Affected individuals must be notified where required, with clear information on the breach and recommended actions. - All breach decisions, assessments and communications must be documented. - A post-breach review must identify root cause and corrective actions. 4. Roles and responsibilities - The [Incident Manager] coordinates the overall response. - The [Data Protection Lead or Legal] determines notification obligations and timeframes. - The [Communications Lead] manages internal and external messaging. - Executive management approves regulatory and customer notifications. 5. Procedures - Triage the report and confirm whether sensitive data is involved. - Contain the breach and preserve evidence. - Assess scope, data categories, number of affected individuals and likely harm. - Decide and execute required notifications within the applicable timeframes. - Maintain a record of the breach and all decisions. - Hold a post-breach review and track corrective actions to closure. 6. Evidence and records Keep the breach record, assessment of harm, notification decisions and content, regulator and customer correspondence, timelines, root cause analysis and corrective actions. 7. Review cadence This policy is reviewed at least annually and after any significant breach or change to notification law. Owner: [role] Version: [x.y] Approved by: [name/role] Date: [date] ``` ## Mobile device and BYOD policy Use for ISO 27001 A.6.7, A.7.9, A.8.1, SOC 2 Security, and controls for remote and personally owned devices. Frameworks: ISO 27001, SOC 2 ```text 1. Purpose This policy defines the security requirements for mobile devices and for personally owned devices used to access company information, so that company data is protected regardless of who owns the device. 2. Scope This policy applies to all smartphones, tablets and personally owned computers used to access company email, systems or data, and to all employees and contractors who use such devices. 3. Policy statements - Access to company data from a personal device is permitted only where the device meets the minimum security requirements and the user accepts this policy. - Devices accessing company data must have a screen lock, a supported operating system and current security updates. - Company data on mobile and personal devices should be contained within managed apps or profiles where possible. - Company data must not be stored in unapproved personal cloud accounts or applications. - The company must be able to remotely remove company data, or the managed work profile, from a device that is lost, stolen or belongs to a leaver. - Jailbroken or rooted devices must not access company data. - Lost or stolen devices must be reported immediately. - Users must not disable required security controls on devices used for work. 4. Roles and responsibilities - The [IT Manager] defines minimum device requirements and manages enrolment. - IT administers mobile device management and remote wipe capability. - The [Security Lead] approves exceptions and reviews compliance. - Users keep their devices compliant and report loss or theft. 5. Procedures - Define the minimum security baseline for mobile and personal devices. - Enrol eligible devices in mobile device management or apply managed app controls. - Require users to accept the policy before access is granted. - Monitor compliance and restrict access for non-compliant devices. - Execute selective wipe of company data at offboarding or on loss. 6. Evidence and records Keep device enrolment and compliance reports, signed user acknowledgements, exception approvals, remote wipe records and lost-device incident tickets. 7. Review cadence This policy is reviewed at least annually and after changes to device management capability. Owner: [role] Version: [x.y] Approved by: [name/role] Date: [date] ``` ## Network security policy Use for ISO 27001 A.8.20, A.8.21, A.8.22, A.8.23, SOC 2 Security, and PCI DSS requirements 1 and 4. Frameworks: ISO 27001, SOC 2, PCI DSS ```text 1. Purpose This policy defines how company networks and network services are designed, controlled and monitored to protect the confidentiality, integrity and availability of information in transit. 2. Scope This policy applies to all company networks, cloud networks, virtual private clouds, firewalls, security groups, remote access services and connections to third parties. It applies to all systems connected to company networks. 3. Policy statements - Network access controls such as firewalls or security groups must restrict traffic to what is required, with default deny on inbound traffic. - Networks must be segmented to separate environments of different sensitivity, such as production, corporate and any cardholder data environment. - Inbound and outbound rules must be documented, justified and reviewed at least every [6] months. - Remote access to internal systems must use encrypted connections and multi-factor authentication. - Wireless networks must use strong encryption and must separate guest access from internal systems. - Data transmitted over public or untrusted networks must be encrypted in transit. - Connections to third parties must be controlled, documented and limited to required services. - Network changes must follow the change management policy. 4. Roles and responsibilities - The [Network or Infrastructure Lead] owns network architecture and firewall rule sets. - IT implements and maintains network controls and remote access. - The [Security Lead] reviews segmentation, rule sets and remote access. - System owners request and justify required network access. 5. Procedures - Maintain network diagrams and a record of firewall or security group rules with justifications. - Apply default deny and add rules only with documented business need. - Review rule sets at least every six months and remove unnecessary rules. - Configure remote access with encryption and multi-factor authentication. - Validate network segmentation periodically, especially around regulated environments. 6. Evidence and records Keep network diagrams, firewall and security group rule sets with justifications, rule review records, remote access configuration, segmentation validation results and change records. 7. Review cadence This policy is reviewed at least annually and rule sets at least every six months. Owner: [role] Version: [x.y] Approved by: [name/role] Date: [date] ``` ## Password and authentication policy Use for ISO 27001 A.5.17, A.8.5, SOC 2 Security, and PCI DSS requirement 8 authentication controls. Frameworks: ISO 27001, SOC 2, PCI DSS ```text 1. Purpose This policy defines the requirements for passwords, multi-factor authentication and other authentication methods used to access company systems, so that only authorised users can gain access. 2. Scope This policy applies to all user accounts, administrator accounts and service accounts on company systems, including cloud platforms, email, identity providers, production systems and code repositories. 3. Policy statements - Each user must have a unique individual account, and shared accounts are prohibited unless explicitly approved and monitored. - Passwords must meet a minimum length of at least [12] characters and be checked against common or breached password lists where supported. - Multi-factor authentication is required for email, identity providers, cloud consoles, production access, code repositories, finance systems and all remote and administrative access. - Where supported, the company should prefer phishing-resistant authentication such as hardware security keys or passkeys for privileged access. - Default and vendor-supplied credentials must be changed before a system is used. - Credentials must not be shared, reused across personal and work accounts, or stored in plaintext. - A company-approved password manager must be used to store work credentials. - Accounts must lock or rate-limit after repeated failed authentication attempts. - Service account credentials must be stored in a secret manager, restricted to required systems and rotated on a defined schedule or on compromise. 4. Roles and responsibilities - The [Security Lead] owns authentication standards and approves exceptions. - IT enforces password and multi-factor settings through the identity provider and system configuration. - System owners ensure their systems meet the authentication requirements. - Users protect their credentials and report suspected compromise. 5. Procedures - Configure password and multi-factor policies centrally where possible. - Enforce multi-factor authentication on all in-scope systems. - Provide and require use of an approved password manager. - Change all default credentials during system setup. - Store and rotate service account secrets through a secret manager. - Review authentication settings and exceptions periodically. 6. Evidence and records Keep identity provider configuration, multi-factor enforcement reports, password policy settings, secret manager records, default credential change records and exception approvals. 7. Review cadence This policy is reviewed at least annually and after material changes to identity systems. Owner: [role] Version: [x.y] Approved by: [name/role] Date: [date] ``` ## Malware protection policy Use for ISO 27001 A.8.7, SOC 2 Security, and PCI DSS requirement 5 anti-malware controls. Frameworks: ISO 27001, SOC 2, PCI DSS ```text 1. Purpose This policy defines how the company prevents, detects and responds to malicious software, including viruses, ransomware, spyware and malicious scripts, so that systems and data are protected from compromise. 2. Scope This policy applies to all company endpoints, servers, virtual machines, cloud workloads, email systems and web browsing, and to all employees and contractors who use company systems or access company data. 3. Policy statements - Approved endpoint protection software must be installed, enabled and kept current on all workstations and servers that support it. - Endpoint protection must include real-time scanning and, where available, behavioural detection and ransomware protection. - Signature and detection engine updates must be applied automatically and at least daily. - Users must not disable, bypass or uninstall malware protection, and administrative controls must prevent this on managed devices. - Email must be filtered for malicious attachments, links and spoofing before delivery to users. - Web filtering must block known malicious sites and unapproved high-risk file downloads where technically practical. - Software may only be installed from approved sources, and execution of unauthorised software should be restricted on managed devices. - Files received from external parties or downloaded from the internet must be scanned before use where scanning is not automatic. - Systems that cannot run endpoint protection must be identified and protected with compensating controls approved by the [Security Lead]. - Confirmed or suspected malware infections must be treated as security events under the incident response policy. 4. Roles and responsibilities - The [Security Lead] owns the malware protection programme, selects approved tooling and approves exceptions. - IT deploys and maintains endpoint protection, email filtering and web filtering, and monitors coverage. - System owners ensure their systems meet these requirements. - All users report suspected infections, suspicious emails and unexpected system behaviour immediately through [reporting channel]. 5. Procedures - Deploy endpoint protection through central management and enrol every eligible device. - Monitor the management console for coverage gaps, outdated agents and detections on a [daily or weekly] cadence. - On detection, isolate the affected device from the network, preserve logs, remove the malware or reimage the device, and reset credentials used on it where compromise is possible. - Verify that email and web filtering rules remain effective after major platform changes. - Review devices without protection and record compensating controls or remediation. 6. Evidence and records Keep endpoint protection coverage reports, update status, detection and quarantine logs, email filtering configuration and reports, incident tickets for infections, isolation and reimage records, and exception approvals. 7. Review cadence This policy is reviewed at least annually and after significant malware incidents or changes to protection tooling. Owner: [role] Version: [x.y] Approved by: [name/role] Date: [date] ``` ## Security awareness and training policy Use for ISO 27001 A.6.3, SOC 2 Security awareness criteria, and PCI DSS requirement 12.6 training obligations. Frameworks: ISO 27001, SOC 2, PCI DSS ```text 1. Purpose This policy defines how the company builds and maintains security awareness among its people, so that employees and contractors understand the threats relevant to their work, their obligations under company policies, and how to report security concerns. 2. Scope This policy applies to all employees, contractors and, where relevant, temporary staff who access company systems or information, from their start date until the end of their engagement. 3. Policy statements - All new starters must complete security awareness training before, or within [x] days of, being granted access to company systems. - All staff must complete refresher training at least annually. - Training content must cover, at minimum: phishing and social engineering, password and MFA practices, safe handling of confidential data, acceptable use, reporting of security events, and safe use of approved AI tools. - Training content must be updated when policies, threats or company tooling change materially. - Phishing simulations must be run at least [quarterly], with results used for education rather than punishment on a first failure. - Staff who fail repeated phishing simulations must receive targeted follow-up training. - Staff in roles with elevated risk, such as developers, administrators, finance and customer support, must receive additional role-specific training relevant to their duties, for example secure coding for developers. - Completion of required training is a condition of continued system access, and non-completion must be escalated to the staff member and their manager. - Awareness communications, such as alerts about current phishing campaigns, must be issued when relevant threats are identified. 4. Roles and responsibilities - The [Security Lead] owns the awareness programme, selects training content and runs phishing simulations. - [HR] ensures training is assigned at onboarding and tracks completion as part of the joiner process. - Managers ensure their teams complete required training on time. - All staff complete assigned training and apply it in their daily work. 5. Procedures - Assign onboarding training automatically when an account is created. - Schedule annual refresher training and send reminders before the due date. - Run phishing simulations, record results and deliver follow-up training to repeat clickers. - Review training content at least annually against current threats and policy changes. - Report completion rates and simulation results to management at least [quarterly]. 6. Evidence and records Keep training completion records with dates, training content versions, phishing simulation schedules and results, follow-up training records, escalation records for non-completion, and management reports. 7. Review cadence This policy and the training content are reviewed at least annually and after material changes to threats, tools or policies. Owner: [role] Version: [x.y] Approved by: [name/role] Date: [date] ``` ## Cloud services and outsourcing policy Use for ISO 27001 A.5.19 to A.5.23, SOC 2 vendor management, and oversight of cloud and outsourced service providers. Frameworks: ISO 27001, SOC 2 ```text 1. Purpose This policy defines how cloud services and outsourced functions are selected, approved, operated and exited, so that the company retains control over its information and obligations when work or data is placed with an external provider. 2. Scope This policy applies to all cloud services, including infrastructure, platform and software as a service, and to any outsourced business or technology function that processes company or customer information or supports critical operations. 3. Policy statements - New cloud services and outsourcing arrangements must be approved by the [Security Lead or IT Manager] before company data is placed in them, and unapproved services must not be used for company work. - Due diligence proportionate to the risk tier must be completed before approval, covering security posture, certifications or assurance reports, data protection terms, subcontractors, incident notification commitments, financial viability and support arrangements. - Data residency must be confirmed before approval, and services storing regulated or customer data must keep it in [approved regions] unless an exception is approved. - A shared responsibility mapping must be documented for each significant cloud service, recording which security controls the provider operates and which the company must operate, such as identity, access, configuration, backup and monitoring. - Contracts must include confidentiality, security requirements, breach notification within [x] hours, audit or assurance rights appropriate to the service, and data return or deletion on termination. - Each approved service must have a named business owner and must be recorded in the cloud services register. - Company-managed controls on cloud services, such as MFA, least privilege access and logging, must be configured before production use. - An exit strategy must be documented for critical services, covering data export formats, migration options, notice periods and how long an exit would take. - Services must be reviewed on a cadence matched to their risk tier, and on contract renewal, major changes or provider incidents. 4. Roles and responsibilities - The [Security Lead] sets the assessment standard, performs or reviews due diligence and approves exceptions. - Business owners justify the need, own the relationship and initiate reviews and offboarding. - IT configures company-managed controls and manages access. - Legal or the contract owner ensures required terms are in place. 5. Procedures - Request approval for a new service through [ticketing system] with the intended data types and users. - Complete the due diligence checklist and assign a risk tier. - Record the service, owner, data types, residency and responsibility mapping in the register. - Review critical services at least annually, and confirm assurance reports remain current. - On exit, export data, confirm provider deletion in writing and remove integrations and access. 6. Evidence and records Keep the cloud services register, due diligence records, assurance reports, contracts and data processing terms, responsibility mappings, review records, exception approvals, exit plans and deletion confirmations. 7. Review cadence This policy is reviewed at least annually and after material changes to providers, regulations or company data flows. Owner: [role] Version: [x.y] Approved by: [name/role] Date: [date] ``` ## Asset management policy Use for ISO 27001 A.5.9, A.5.10, A.5.11, A.7.9 to A.7.14, SOC 2 Security, and PCI DSS asset inventory expectations. Frameworks: ISO 27001, SOC 2, PCI DSS ```text 1. Purpose This policy defines how information and the assets that support it are identified, recorded, owned, handled, returned and disposed of, so that the company knows what it has, who is responsible for it, and that assets are protected throughout their life cycle. 2. Scope This policy applies to all assets associated with information and information processing, including hardware such as laptops, mobile devices, servers and removable media, software and SaaS subscriptions, cloud resources, information assets such as databases and repositories, and supporting services. It applies to all employees and contractors who are issued or handle company assets. 3. Policy statements - An inventory of assets must be maintained and kept accurate, recording at minimum the asset, its owner, its location or hosting, its classification and its status. - Every asset in the inventory must have a named owner responsible for its protection, appropriate handling and life cycle decisions. - Assets must be handled in accordance with the classification of the information they store or process, as defined in the information classification policy. - Company equipment must not be modified, lent or used in ways that compromise its security controls, and must be physically protected when off premises. - Removable media may be used only where approved, must be encrypted when carrying confidential data, and must be tracked while in use. - All company assets, including devices, media, access cards and documentation, must be returned on termination of employment or engagement, or when no longer required for the role. - Equipment and media containing company data must be securely sanitised or physically destroyed before disposal, resale, return to a lessor or reuse, using methods that prevent data recovery. - Disposal of assets must be recorded, and bulk or third-party destruction must be supported by a certificate of destruction. - Unaccounted-for assets must be investigated, and lost assets containing company data must be reported as security events. 4. Roles and responsibilities - The [IT Manager] maintains the asset inventory and manages issue, return and disposal of equipment. - Asset owners approve access to and handling of their assets and confirm inventory accuracy. - [HR] triggers asset return at offboarding and confirms completion with IT. - All staff take reasonable care of assigned assets and report loss, theft or damage immediately. 5. Procedures - Record new assets in the inventory at procurement or creation, and assign an owner. - Issue equipment to staff against a signed record of receipt. - Reconcile the inventory at least [annually] against device management and procurement records. - At offboarding, collect all assets, confirm return against the issue record and wipe or reassign devices. - Sanitise storage using secure erase, cryptographic erasure or physical destruction, and record the method, date and person responsible. 6. Evidence and records Keep the asset inventory, issue and return records, reconciliation results, sanitisation and disposal logs, certificates of destruction, lost asset incident tickets and exception approvals. 7. Review cadence This policy is reviewed at least annually and after significant changes to equipment, hosting or ways of working. Owner: [role] Version: [x.y] Approved by: [name/role] Date: [date] ``` ## ISMS internal audit procedure How to plan and run internal ISMS audits under ISO 27001 clause 9.2, from programme to follow-up. Frameworks: ISO 27001 ```text 1. Purpose This procedure defines how [Company Pty Ltd] plans, conducts and follows up internal audits of the Information Security Management System (ISMS), so that management receives objective evidence that the ISMS conforms to ISO/IEC 27001:2022 and to our own requirements, and that it is effectively implemented and maintained. 2. Scope Applies to all processes, controls, teams and locations inside the ISMS scope statement, including outsourced processes for which [Company] retains responsibility. 3. Audit programme 3.1 The [ISMS Manager] maintains a rolling audit programme covering every ISMS clause and every applicable Annex A control at least once per [certification cycle, typically 3 years], with higher-risk areas audited at least annually. 3.2 Programme inputs: risk assessment results, incident history, prior audit findings, changes to systems or suppliers, and certification body feedback. 3.3 The programme records, for each audit: scope, criteria, method (interview, document review, technical sampling), auditor, and planned month. 4. Auditor independence and competence 4.1 Auditors must not audit their own work or areas they manage. Where the team is small, use a trained auditor from another function, a peer company arrangement, or an external contractor. 4.2 Auditors must have completed [internal auditor training / ISO 27001 lead auditor course] and be approved by the [ISMS Manager]. 5. Planning each audit 5.1 At least [10] business days before fieldwork, the auditor issues an audit plan stating scope, criteria (ISO 27001 clauses, Annex A controls, internal policies), interviewees, and evidence to be sampled. 5.2 Auditees confirm availability and pre-supply requested documents. 6. Fieldwork 6.1 Open with a short briefing confirming scope and method. 6.2 Gather objective evidence: interview staff, review records, observe practice, and sample system configurations. Record what was examined, not only conclusions. 6.3 Test that controls operate as described, not merely that documents exist. 7. Findings and reporting 7.1 Classify each finding as: major nonconformity, minor nonconformity, observation, or opportunity for improvement, with the criterion breached and the evidence. 7.2 Issue the audit report to the auditee and [top management] within [5] business days of fieldwork. 7.3 Nonconformities enter the corrective action process per the [Nonconformity and Corrective Action Procedure]. 8. Follow-up The auditor verifies completion and effectiveness of corrective actions by [agreed due dates] and records closure. Overdue actions are escalated to [management review]. 9. Roles and responsibilities [ISMS Manager]: owns the programme and this procedure. Auditors: plan, execute, report, verify closure. Auditees: provide access and evidence, own corrective actions. [Top management]: receives results, resources the programme. 10. Records Retain the audit programme, audit plans, evidence notes, reports and closure records for at least [3] years in [location]. 11. Review Review this procedure at least annually and after any certification audit. Owner: [ISMS Manager]. Version: [x.y]. Approved by: [name/role]. Date: [date]. ``` ## Management review procedure Runs the clause 9.3 management review, with a standing agenda, required inputs, outputs and action tracking. Frameworks: ISO 27001 ```text 1. Purpose This procedure defines how [Company Pty Ltd] top management reviews the ISMS at planned intervals, per ISO/IEC 27001:2022 clause 9.3, to confirm it remains suitable, adequate and effective, and to decide on changes and resources. 2. Scope Covers the full ISMS scope. Applies to [CEO, CTO, ISMS Manager, and heads of relevant functions]. 3. Cadence and attendance 3.1 Reviews are held at least [twice per year / quarterly], and additionally after a major incident, significant organisational change, or an adverse audit result. 3.2 Quorum requires [the CEO or delegate] plus the [ISMS Manager]. The [ISMS Manager] chairs and prepares the input pack, circulated at least [5] business days before the meeting. 4. Required inputs The input pack must address every clause 9.3.2 item: status of actions from previous reviews; changes in external and internal issues relevant to the ISMS; changes in interested party needs and expectations; feedback on security performance including nonconformities and corrective actions, monitoring and measurement results, audit results, and fulfilment of security objectives; feedback from interested parties; risk assessment results and risk treatment plan status; and opportunities for continual improvement. 5. Standing agenda 1. Actions from the previous review: status and overdue items 2. Changes to internal and external issues, and to interested party requirements 3. Security objectives: performance against metrics and targets 4. Internal and external audit results 5. Nonconformities, corrective actions and their effectiveness 6. Incidents, near misses and lessons learned since last review 7. Risk assessment update and risk treatment plan progress 8. Risk acceptance decisions requiring management sign-off 9. Supplier and third party security performance 10. Resources: budget, staffing, training needs 11. Opportunities for continual improvement 12. Decisions, new actions, owners and due dates 6. Outputs Recorded decisions must cover: continual improvement opportunities adopted, any needed changes to the ISMS (scope, policy, objectives, risk criteria), and resource decisions. Each action gets an owner and a due date. 7. Minutes and action tracking 7.1 The [ISMS Manager] issues minutes within [5] business days, capturing attendees, inputs considered, decisions and actions. 7.2 Actions are logged in the [action register / ticketing system] and tracked to closure; overdue actions open the next review. 8. Roles and responsibilities [Top management]: attends, decides, allocates resources. [ISMS Manager]: schedules, prepares inputs, chairs, records, chases actions. Function heads: supply input data for their areas. 9. Records Retain input packs, minutes and action logs for at least [3] years in [location]; these are primary evidence for clause 9.3 at certification audits. 10. Review Review this procedure annually. Owner: [ISMS Manager]. Version: [x.y]. Approved by: [name/role]. Date: [date]. ``` ## Nonconformity and corrective action procedure Handles clause 10.1 end to end: raising nonconformities, containment, root cause, corrective action and effectiveness checks. Frameworks: ISO 27001 ```text 1. Purpose This procedure defines how [Company Pty Ltd] reacts to nonconformities in the ISMS, corrects them, addresses their causes so they do not recur, and records the results, per ISO/IEC 27001:2022 clause 10.1. 2. Scope Applies to any failure to meet a requirement of ISO/IEC 27001, our own policies and procedures, legal or contractual security obligations, or planned control operation. Sources include internal and external audits, incidents, monitoring results, supplier reviews, and staff reports. 3. Raising a nonconformity (NC) 3.1 Anyone may raise an NC via [ticketing system / form / email to ISMS Manager]. 3.2 Each NC record states: what requirement was not met, the objective evidence, where and when it was found, and who raised it. 3.3 The [ISMS Manager] triages within [2] business days, assigns a unique ID (NC-[YYYY]-[nn]), a severity ([major/minor]) and an owner. 4. Immediate correction and containment 4.1 The owner takes action to control and correct the nonconformity and to deal with its consequences, for example disabling an exposed account, restoring a control, or notifying affected parties. 4.2 If the NC involves a security incident, invoke the [Incident Response Plan] in parallel; the NC record links to the incident record. 5. Root cause analysis 5.1 For every major NC, and for minor NCs at the owner discretion or where a pattern exists, evaluate the need for action to eliminate the cause. 5.2 Use a structured method such as [5 Whys / fishbone analysis], and check whether similar nonconformities exist or could occur elsewhere in the ISMS. 5.3 Record the root cause, distinguishing symptom (what happened) from cause (why the system allowed it). 6. Corrective action 6.1 Define actions proportionate to the effects of the NC, with owner and due date: [major NCs within 30 days, minor within 90 days, or as agreed]. 6.2 Update risk assessments, policies, training or the Statement of Applicability where the cause reveals a gap in them. 7. Effectiveness check After actions complete, the [ISMS Manager] or an independent reviewer verifies, after a suitable operating period of [30 to 90] days, that the NC has not recurred and the control now operates. Ineffective actions reopen the NC. 8. Register and reporting The [ISMS Manager] maintains an NC register with columns: ID, date raised, source, description, severity, owner, correction, root cause, corrective action, due date, effectiveness check result, closure date. Trends and open items are reported to every management review. 9. Roles and responsibilities All staff: report suspected NCs. NC owner: correction, root cause, actions. [ISMS Manager]: triage, register, verification, reporting. [Top management]: resources and escalation path for overdue majors. 10. Records Retain NC records and the register for at least [3] years in [location] as clause 10.1 evidence. 11. Review Review annually. Owner: [ISMS Manager]. Version: [x.y]. Approved by: [name/role]. Date: [date]. ``` ## Information risk management procedure The clause 6.1.2/6.1.3 and 8.2/8.3 engine: risk identification, analysis scales, evaluation, treatment, acceptance and review. Frameworks: ISO 27001 ```text 1. Purpose This procedure defines how [Company Pty Ltd] identifies, analyses, evaluates and treats information security risks, per ISO/IEC 27001:2022 clauses 6.1.2, 6.1.3, 8.2 and 8.3, so that risk decisions are consistent, repeatable and produce comparable results over time. 2. Scope All information assets, processes, people, suppliers and technology within the ISMS scope statement. 3. Risk criteria 3.1 Likelihood scale (1 to 5): 1 Rare (less than once in 5 years), 2 Unlikely (once in 2 to 5 years), 3 Possible (once a year), 4 Likely (several times a year), 5 Almost certain (monthly or more). 3.2 Impact scale (1 to 5) considering confidentiality, integrity and availability: 1 Negligible, 2 Minor (limited internal disruption), 3 Moderate (customer impact or cost above [$10k]), 4 Major (regulatory report, cost above [$100k]), 5 Severe (existential, mass data breach). 3.3 Risk score = likelihood x impact. Acceptance threshold: scores of [6] or below may be accepted by the risk owner; [8 to 12] require [ISMS Manager] approval; above [12] require [top management] approval. 4. Risk identification 4.1 The [ISMS Manager] runs a full assessment at least annually and a targeted assessment on significant change (new system, supplier, market, or major incident). 4.2 Identify risks by considering assets and their owners, threats, vulnerabilities, incident history, audit findings and interested party requirements. Every risk gets a named risk owner. 5. Risk analysis and evaluation 5.1 Rate likelihood and impact using section 3 scales, taking existing controls into account (current risk). 5.2 Compare scores against the acceptance threshold and rank risks to produce a prioritised list for treatment. 6. Risk treatment 6.1 For each risk above threshold choose: modify (apply controls), retain (accept with approval), avoid (stop the activity), or share (insurance, outsourcing, contracts). 6.2 Where modifying, select controls, compare them against Annex A to confirm nothing necessary has been overlooked, and update the Statement of Applicability with inclusion and exclusion justifications. 6.3 Produce a risk treatment plan: risk ID, chosen option, controls, owner, due date, expected residual score. 6.4 Obtain risk owner approval of the plan and explicit acceptance of residual risks, recorded with name and date. 7. Risk register Maintain the register in [tool/spreadsheet] with columns: ID, asset or process, description, threat, vulnerability, likelihood, impact, score, owner, treatment option, controls, residual score, acceptance approver, next review date. 8. Monitoring and review Review the full register at least [quarterly]; report movements, new risks and overdue treatments to management review. Reassess any risk on relevant incident or control failure. 9. Roles and responsibilities [ISMS Manager]: method, facilitation, register. Risk owners: ratings, treatment decisions, acceptance. [Top management]: approves criteria and high risk acceptances. 10. Records Retain assessments, treatment plans and acceptance records for at least [3] years in [location]. 11. Review Review this procedure and the criteria in section 3 annually. Owner: [ISMS Manager]. Version: [x.y]. Approved by: [name/role]. Date: [date]. ``` ## Remote and hybrid working policy Use for ISO 27001 A.6.7, remote and hybrid work arrangements, home office security, and SOC 2 endpoint and access controls. Frameworks: ISO 27001, SOC 2 ```text 1. Purpose This policy defines the security requirements that apply when staff work away from company premises, including working from home, while travelling, and in public or shared spaces. It exists so that the confidentiality, integrity and availability of company and customer information does not depend on where the work happens. 2. Scope This policy applies to all employees, contractors and third parties who access company information or systems from any location outside company-controlled offices, using company-issued or approved personal devices. 3. Policy statements - Remote work is permitted only on devices that meet the requirements of the [endpoint and mobile device policy], including disk encryption, screen lock, endpoint protection and a supported operating system. - Home networks used for company work must have the router administrator password changed from the default, use WPA2 or WPA3 encryption, and have remote administration disabled. - Company information must be accessed only through approved tools and services listed in [approved tools register]. Personal email, personal cloud storage and unapproved messaging apps must not be used for company data. - In public or shared spaces, staff must use a privacy screen where practical, position screens away from overlooking, never leave devices unattended, and avoid discussing confidential matters where they can be overheard. - Public wifi may be used only with [company VPN or equivalent protection] enabled. Public charging cables and unknown USB accessories must not be used with company devices. - Confidential papers must not be printed at home or in public facilities unless approved by [role], and must be stored locked and destroyed by [cross-cut shredding or approved return process]. - Household members and other third parties must not use company devices or view company information. 4. Roles and responsibilities - Staff: comply with this policy, maintain their home working environment, and report issues. - Managers: confirm remote arrangements are appropriate for the role and data involved. - [IT or security lead]: maintain the approved tools register, VPN and device controls. 5. Procedures - New remote workers complete the [remote work checklist] before their first remote day. - Exceptions are requested through [ticketing system] and approved by [role]. - Lost or stolen devices, suspected compromise, or accidental disclosure while remote must be reported to [security contact] within [1 hour] of discovery. 6. Evidence and records Keep signed policy acknowledgements, remote work checklists, VPN and device management enrolment reports, exception approvals and incident tickets relating to remote work. 7. Review Owner: [role]. Reviewed at least annually and after any incident or material change to remote working arrangements. ``` ## Email and communications security policy Use for ISO 27001 A.5.14 and A.8.24, information transfer, encryption in transit, phishing response, and SOC 2 communication controls. Frameworks: ISO 27001, SOC 2 ```text 1. Purpose This policy defines how company email and other communication channels are used and protected, so that information sent inside and outside the company is transferred securely, phishing is handled consistently, and records are retained appropriately. 2. Scope This policy applies to all staff and contractors using company email, chat, video conferencing, file sharing and any other channel used to transmit company or customer information. 3. Policy statements - Company business must be conducted only through approved channels listed in [approved communications register], such as [company email, chat platform, video tool]. Personal accounts must not be used for company business. - Email in transit must be protected by TLS. Mail to domains that cannot support encrypted transport must not carry Confidential or Restricted information. - Confidential or Restricted content sent externally must use [message encryption feature, secure file share link, or approved portal] rather than plain attachments. Credentials, keys and card data must never be sent by email or chat. - Automatic forwarding of company mail to external addresses is prohibited. Manual forwarding of Confidential material outside the company requires a business need and, where required, approval from [role]. - Staff must verify unusual or high-risk requests received by email, such as payment changes or credential requests, through a second channel before acting. - Suspected phishing must not be replied to, clicked or forwarded to colleagues. It must be reported using [report button or security contact] immediately. Anyone who has clicked a link or entered credentials must report it at once; early reporting is never penalised. - Distribution lists and external sharing settings must be reviewed before sending bulk or sensitive communications, and recipients checked before sending. 4. Roles and responsibilities - Staff: use approved channels, apply encryption rules, report phishing. - [IT or security lead]: maintain mail security controls such as SPF, DKIM, DMARC, filtering and alerting, and run phishing awareness activities. - Managers: reinforce reporting culture and escalate repeated issues. 5. Procedures - Reported phishing is triaged by [security contact] within [4 hours]; confirmed campaigns trigger the [incident response policy]. - Requests to send Restricted data externally are raised in [ticketing system] for approval. - Mailbox retention follows the [retention schedule]; legal holds override deletion when instructed by [role]. 6. Evidence and records Keep phishing reports and triage records, mail security configuration exports, DMARC reports, forwarding rule audit results, external transfer approvals, retention settings and training completion records. 7. Review Owner: [role]. Reviewed at least annually and after significant phishing incidents or changes to communication platforms. ``` ## Clear desk and clear screen policy Use for ISO 27001 A.7.7, physical protection of papers and screens, printing controls, and office and visitor area practices. Frameworks: ISO 27001 ```text 1. Purpose This policy defines the rules for keeping papers, removable media and screens free of exposed information when unattended, so that Confidential and Restricted information cannot be read, photographed or removed by unauthorised people. 2. Scope This policy applies to all staff, contractors and visitors in company offices, home offices, co-working spaces and any other location where company information is displayed or handled physically. 3. Policy statements - Screens must lock automatically after no more than [10] minutes of inactivity, and staff must lock screens manually with [shortcut] whenever leaving a device unattended, even briefly. - Desks must be cleared of papers, notebooks and removable media containing Internal, Confidential or Restricted information at the end of each day and whenever leaving the desk for an extended period. Such material must be stored in [lockable drawers or cabinets]. - Passwords, access codes and keys must never be written on notes, whiteboards or visible surfaces. - Printing of Confidential or Restricted documents must be collected immediately. Where available, [secure print release] must be used. Uncollected print jobs found at printers must be handed to [role] or destroyed. - Paper and media requiring disposal must go into [locked shred bins or a cross-cut shredder], never general waste or recycling. - Whiteboards and flip charts must be erased after meetings that involve Confidential information, and meeting room screens disconnected or cleared before leaving. - In visitor areas and meeting rooms visible to visitors, no Confidential material may be left on display. Visitors must be escorted and must not be left alone in work areas. - Screens in reception, shared or public-facing positions must be angled or fitted with privacy filters so that passers-by cannot read them. 4. Roles and responsibilities - Staff: follow clear desk and clear screen practices at all locations. - Managers: address repeated non-compliance within their teams. - [Office manager or security lead]: provide lockable storage, shred bins and privacy filters, and run periodic walkthroughs. 5. Procedures - [Role] performs a documented clear desk walkthrough at least [quarterly], recording findings and corrective actions. - Findings such as exposed documents or unlocked screens are logged in [ticketing system] and raised with the individual and their manager. - Screen lock timeouts are enforced centrally through [device management tool]. 6. Evidence and records Keep walkthrough checklists and findings, corrective action records, device management screen lock configuration reports, shredding or secure destruction certificates and policy acknowledgements. 7. Review Owner: [role]. Reviewed at least annually and after office moves or repeated findings. ``` ## Information security roles and responsibilities Use for ISO 27001 A.5.2, A.5.3 and A.5.4, defining security roles, segregation of duties, management responsibilities, and SOC 2 organisational controls. Frameworks: ISO 27001, SOC 2 ```text 1. Purpose This policy defines and allocates information security roles so that every security responsibility has a named, accountable owner, conflicting duties are separated, and staff know who decides, who does the work and who must be informed. 2. Scope This policy applies to all employees, contractors and governance bodies of [Company Pty Ltd], and covers all activities within the ISMS scope. 3. Policy statements - Every control, asset, risk and policy in the ISMS must have a named owner recorded in [ISMS register]. Ownership follows the role, not the person, and transfers automatically on role change. - Duties must be segregated so that no single person can request, approve and implement the same high-risk change, or grant themselves privileged access. Where headcount makes separation impractical, [compensating monitoring or independent review] must be documented and approved by [role]. - Security responsibilities must be stated in employment contracts, position descriptions and supplier agreements. 4. Roles and responsibilities - [CEO or managing director]: ultimately accountable for information security; approves the information security policy, risk appetite and ISMS resourcing; is informed of all SEV1 incidents. - [CISO or security lead]: accountable for operating the ISMS; runs risk assessments, coordinates internal audits and management reviews, reports ISMS performance to leadership at least [quarterly], and is the escalation point for security decisions. - Asset owners: accountable for the protection of their assets; approve access, set classification, and accept or escalate risks affecting their assets. - Risk owners: accountable for individual risks in the [risk register]; decide treatment, track actions to closure and formally accept residual risk within delegated limits. - [IT lead or system administrators]: responsible for implementing technical controls, provisioning approved access and maintaining logging and backups; consulted on all changes affecting security. - Managers: responsible for ensuring their teams complete training, follow policies and report events; consulted on role changes affecting access. - All staff: responsible for following policies, protecting information they handle and reporting suspected security events immediately; informed of policy changes through [channel]. 5. Procedures - Escalation path: staff report to their manager or [security contact]; the [security lead] escalates to [CEO] for SEV1 incidents, risk acceptances above [threshold] and legal notification decisions. - The role register is updated within [5] business days of any appointment, departure or restructure. - Deputies are named in [register] for the [security lead] and each asset owner to cover absence. 6. Evidence and records Keep the role and ownership register, signed position descriptions, delegation and deputy records, segregation of duties matrix, risk acceptance records, management review minutes and escalation records. 7. Review Owner: [role]. Reviewed at least annually, after organisational changes and after any audit finding on accountability. ```