SOC 2 Policy Templates

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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.

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.

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.