Last updated February 2025.

The table below sets out the minimum security standards (standards) that the Christchurch City Council (Council, we, our or us) requires from you.

The Council aims to review these standards annually. Please check our website periodically to ensure you are following the most current version of these standards.

These standards form part of the agreement we have with you for the provision of goods and/or services (agreement) and will be read together with that agreement.

You warrant that you:

  • Comply with these standards at all times during the term of our agreement; and
  • Will provide us with information demonstrating your compliance, when we request it.

In the event of any inconsistency between these standards and any other general warranty or contractual commitment you have agreed with us, these standards will prevail (unless we have expressly agreed otherwise).

Any breach of these standards will constitute a breach of our agreement and you may be liable to us for damages and other available contractual remedies.

If the following applies to you, then you do not need to meet these standards:

  • You are acting as a technology provider to, or for, us and your technology is hosted on our premises where we are implementing and maintaining technology controls.
  • Your technology is a cloud service or public cloud service and we are implementing and maintaining technology controls.
Control (Process) Minimum standard
Governance and information security management system (ISMS) You will have an Information Security Policy that:
  • meets, or is equivalent to, the standards set by ISO 27001; and
  • is reviewed at least annually and following any changes to the service.
Information security management system – scope You understand the scope of the service you provide, including:
  • what data is in scope;
  • where data is stored, hosted, processed, and transmitted;
  • who has access to the data, including onward transmission to third parties;
  • your controls to protect data (as per these minimum standards); and
  • data flow mapped including all systems used to provide the service.
Information security management system – management information and reporting You will document your ISMS compliance management and assessment process, showing your:
  • methods to test compliance to controls within the ISMS;
  • compliance and non-compliance reporting to management;
  • governance framework with appropriate escalation;
  • exceptions to policy; and
  • how you identify and update on threats.
Information security management system – documentation Your ISMS policy will be:
  • documented;
  • appropriately approved by your management;
  • version controlled; and
  • assigned to appropriate owners.
Information security management system – training (standard)
  • Your staff will be regularly trained on how to protect your customers and your customer’s data.
  • Your staff, who work on our services, will complete relevant security awareness training before working on or supporting, any service provided to us.
Risk – threats You will keep your outsider threat knowledge up-to-date, for example by attending forums and dispersing within your organisation current knowledge and best practices around threat protection.
Asset management – policy
  • You will have documented procedures in place, ensuring that a current, complete, and accurate information asset inventory is maintained at all times.
  • You will ensure that any devices used to access our network are patched and all software, including anti-virus software, is up-to-date.
  • You will ensure that end-of-life processes are in place with best-practice practice device-wiping.
  • Your documented procedures will cover the following:
    • Planning: Establish and verify asset requirements;
    • Acquisition: Appropriate and fit-for-purpose;
    • Operation and maintenance: Application and management of an asset, including maintenance and support lifecycle management (e.g. the tracking of end of life/support); and
    • Decommissioning and disposal.
Asset management – register Your asset register will:
  • Record physical devices and systems, software applications and platforms including websites, external IT systems, critical supplier relationships, and virtual/cloud-based assets;
  • be kept up-to-date;
  • be tested to ensure compliance (e.g. annual check that all applications are included plus sample test of supporting assets every quarter); and
  • include classification of the asset to at least our standards.
Investigation authorisation You will have a documented policy for procedures that establishes management responsibilities for a quick, effective, and orderly response to incidents including:
  • the process if criminal or wrongdoing is suspected;
  • containment, preservation of evidence including chain of custody;
  • triage and corrective actions to support service level agreements;
  • root cause and trend analysis;
  • categorisation, e.g. type and potential impact, and how to manage them;
  • internal escalation, including when your client is notified;
  • engagement of specialist companies, e.g. who, for what type of incident and how to contact them; and
  • reasonable access to the necessary information to assist in any investigations by a client or supplier.
  • Incidents include (but are not limited to):
    • social media,
    • unauthorised logical access; and
    • unauthorised physical access
Joiners movers leavers (JML) – policy
  • You will document what, how, and when access is provisioned and removed, e.g. user access policy (this may be Council-owned for Council systems).
  • You have a documented JML process for the following:
    • authorisation for any changes;
    • authorisation from a line manager before accounts that have been disabled for more than two weeks is re-enabled or reactivated;
    • any circumstances allowing pre-approval, e.g. setup of a laptop allows for the setup of remote access;
    • privileged access/special accounts;
    • least privilege/segregation of duties;
    • management of shared/system accounts
    • recycling equipment; and
    • roles, abilities, and functions defined and documented including trust/permissions (e.g. read-only).
Application – ownership
  • Someone, e.g. an application owner, will be accountable for access to systems.
  • Either through policy or technical control:
    • only specified people will grant access to the system;
    • access can only be granted after line manager approval is provided;
    • segregation of duties will be followed, i.e. authorisers cannot also be system administrators or perform any other function that would allow authorisation and completion of a request;
    • maintain 'least privilege', i.e. access is based on role and function; and
    • Access Control Lists (ACLs) must be maintained for each system.
Application – privilege access In addition to standard user access controls, controls on privilege (including administrator) access will include the following controls:
  • user accounts with privileged access will have this clearly attributed (e.g. recorded in the account properties), and subject to user access reviews at least every six months;
  • the privileged access provisioning and review process will include and record approvals appropriate to the level and type of access being granted, and  mindful of any potential for privileged access to override segregation of duties controls;
  • privileged user access is to be logged, tracked, and reported
  • any privileged action in any environment where group data is handled or stored will be demonstrably linked to an agreed and approved change/service request;
  • elevated access privileges will only be invoked where required and their use limited (as far as is practical) to the context in which they are required;
  • standard user activities such as accessing email, or the internet will not be permitted while elevated access privileges are invoked; and
  • authentication is required in order to use elevated access privileges (see privileged passwords below).
Application – incident management Any unauthorised information disclosure will:
  • follow incident management policy; and
  • lead to an immediate review of current least/privilege access standards.
Protection of authentication information You will have a documented and adhered to password policy/processes including:
  • the hard requirement that passwords are changed in the event of a real or suspected compromise;
  • requests for password changes/resets verified and tracked;
  • only allowing passwords; to be issued to the correct individual
  • password changes upon first logon being enforced, this includes a password reset where a manager or IT desk may know the password;
  • the requirement that vendor-supplied default passwords and security settings are swiftly and always changed; and
  • passwords being stored using one-way encryption, e.g. hashing.
Secure system access authentication
  • Where you follow the National Institute of Standards and Technology (NIST), or any other industry standard, you will document this and record how the standard is met or not met.
  • If you do not follow a standard, you will meet the following:
    1. Short passwords:
      • minimum length = 8 and includes standard complexity requirements
      • users cannot re-use the previous 5 passwords
      • expires after 90 days
      • 5 unsuccessful attempts
      • locked out for 20 minutes
    2. Long passwords:
      • minimum length = 12 and includes standard complexity requirements
      • users cannot re-use the previous 10 passwords
      • expires after 90 days
      • 5 unsuccessful attempts
      • locked out for 60 minutes
    3. Privileged passwords:
      • minimum Length = 14 and includes standard complexity requirements
      • users cannot re-use the previous 5 passwords
      • expires after 30 days
      • 3 unsuccessful attempts
      • locked out for 60 minutes
    4. All user sessions will time out after no more than 30 minutes of inactivity.
Logical identity configuration
  • You will have a policy or procedure that requires all users (including any privileged and operational accounts) to be issued a unique system identification.
  • The identification will be associated with a sole, identifiable individual.
Unique identification – exceptions All known exceptions, e.g. applications that do not support unique identification or administrator/master accounts will:
  • follow a documented standard;
  • record any compensating controls, e.g. proactive monitoring of event logs, break-glass procedure;
  • maintain evidence to prove account access metadata; and
  • have ownership and accountability for the account and any changes.
Ownership of accounts and groups Logs and records will be maintained in order to:
  • identify ownership of client or shared accounts and access groups for systems involving our information; and
  • when and to whom ownership was re-attributed.
Monitoring user access Standards will enforce:
  • annual recertification for standard accounts;
  • six-monthly recertification for privileged accounts;
  • methods for tracking access and response; and
  • a process for escalations.
Removal of access – policy You will have documented standards in place that explicitly define the timeframe for the revocation of user accounts to systems, e.g. application/database/operating system/building, involving our information and include:
  • revocation for movers;
  • a process for emergency revocation; and
  • physical assets, e.g. laptops and door access tokens, must be returned on the last day of work.
Removal of access – controls Access will be removed:
  • within 24 hours or 1 working day of your user leaving;
  • immediately in cases of emergency revocation;
  • upon notice where an account is no longer required or when an account has not been used for 31 days (unless otherwise agreed with us); and
  • on the last day of service for high-risk systems (e.g. AD, VPN, DMS).
Removal of access – logs You will maintain logs to evidence adherence to the procedure, including:
  • when removal of access was requested and by whom;
  • date and time the user left; and
  • date and time the account was revoked.
Remote and administrative access – policy You have a policy or procedure ensuring that all remote access will:
  • Enforce multi-factor authentication (MFA);
  • enforce encryption;
  • require authorisation and approval prior to being granted;
  • be recertified periodically; and
  • log events for possible breaches which must be reviewed proactively.
Remote and administrative access – controls Your technical controls will support your remote access policy or procedure, including:
  • enforcing encryption of the transmission of our confidential and highly confidential information;
  • logging user activity including who connected and when; and
  • restricting access to authorised individuals.
Remote and administrative access – management access/consoles Support/management access will be provided securely. This means, without limitation, that:
  • you have a dedicated secure network to provide management access to infrastructure (including cloud);
  • access accounts for remote support is only enabled for the duration needed and monitored when in use;
  • the network is MFA enforced; and
  • access is restricted to specific IP addresses.
Logging and monitoring – policy
  • You will have an active policy or procedure to record the following:
    • administration activities;
    • staff activities not associated with our work or environment; and
    • events by privileged users/privileged access.
  • Your logs will be protected “for life” (or at least 12 months) and are proactively and reactively monitored.
Logging and monitoring – configuration Events recorded/logged will include at least:
  • all individual access to sensitive data;
  • all actions taken by any individual with root or administrative privileges;
  • access to all audit trails;
  • invalid logical access attempts;
  • use of and changes to identification and authentication mechanisms (e.g. creation of new accounts changes/elevation to privileged accounts);
  • the initialisation, stopping or pausing of audit logs;
  • creation and deletion of system-level objects;
  • system logon/logoff (success and failure);
  • use of escalated rights or administrative functions;
  • access of sensitive system resources (success and failure);
  • change or escalation of rights/privileges;
  • change to audit policies (success and failure);
  • change to audit logs (success and failure);
  • anti-virus and malware events;
  • intruder detection/prevention system events; and
  • changes made to virtual machine images regardless of their running state (e.g., dormant, off or running).
Logging and monitoring – storage and security Logs will:
  • be made available and protected from change/deletion;
  • be retained for a minimum period of 12 months;
  • be secured:
    • physical and logical access to logs/log server must be restricted
    • changes or deletion of logs creates an alert; and
    • log server segregated from the operational environment.
  • have event data is aggregated and correlated from multiple sources and sensors.
Logging and monitoring – review and reporting
  • Events will be analysed to understand attack targets and methods.
  • Data will be aggregated and correlated from multiple sources and sensors.
  • If manual, your logs will be reviewed at least monthly.
  • You will configure and issue alerts for potential breaches, e.g. brute force attacks.
  • You will investigate all potential incidents and follow the incident response procedure, where appropriate.
System time You will have a documented approach to maintaining clock synchronisation across all systems, which must include:
  • all systems ultimately deriving their time from the same authoritative time source; and
  • time synchronisation status is subject to active monitoring or regular checks (at least weekly), with any failures or out-of-band devices being identified and investigated.
Data classification – policy You will have a policy with supported procedures for how you:
  • classify our information;
  • classify assets that access or hold our information;
  • protect information assets;
  • report and remedy any unauthorised disclosure of our information (the unauthorised disclosure of our information is expressly prohibited);
  • report all other incidents;
  • only store our information on authorised systems.
Data loss protection (DLP) – data at rest (confidential) You will protect our confidential data at rest through at least the following:
  • encryption when used in off-premises cloud and/or shared services providers;
  • logical access controls applied to restrict access to those working on our work; and
  • logically separating our confidential data from other client data, e.g. database, file share.
Data loss protection – data at rest (highly confidential)
  • Highly confidential data at rest will be further protected through:
    • encryption; and
    • changing access permissions to the content e.g. making it shareable will be logged/recorded.
  • Where encryption is not possible, you will perform a risk assessment, which we must approve, before proceeding with any of our work associated with highly confidential data. Your risk assessment must consider the following compensating controls:
    • data is hosted inside a data centre or technical room;
    • strong access controls, with regular access recertification (minimum every 3 months);
    • all access requests are subject to independent approval by business area line management;
    • all IT-privileged accounts are managed;
    • logging and monitoring are performed in compliance with our IT security standards (e.g. security logs are integrated with IT SOC SIEM solution);
    • database activity monitoring is in place (for any database holding highly confidential data; and
    • our application owner approves the lack of encryption and re-certifies the solution annually as part of the risk review process.
Data loss protection – data at rest All environments will be considered including non-production and backups.
Data loss protection – hard copy
  • All confidential and highly confidential data will be physically secured e.g. a locked cabinet.
  • Highly confidential data will be delivered via secure point-to-point courier (same-day direct delivery) or by hand.
  • Confidential information will be delivered via secure courier track and trace (next-day delivery) or other agreed method.
Data leakage – local drives
  • Where our information can be saved to hard disk, technical controls will enforce hard disk-level encryption and encryption when machines will be turned off.
  • Checks will be performed to assure that devices are encrypted.
  • You will maintain a record of all completed checks and investigate and report any exceptions.
Data leakage – exfiltration Where our confidential or highly confidential data is stored or processed in a production environment, you will maintain controls that minimise the risk that users with privileged or administrative access to that production environment exfiltrate that data into other environments, such as your wider corporate IT environment or any non-production environment.
Data leakage – internet content filtering tools
  • Access to sites (for personal use) where any of our confidential data can be shared will be blocked including, but not limited to:
    • Webmail, e.g. Gmail
    • file-sharing sites such as Dropbox, Google Drive
    • social media (Facebook, LinkedIn, etc are allowed but the ability to upload files/copy and paste information into a message will be blocked); and
    • instant messaging.
  • Where corporate versions of Gmail, Yahoo, etc are used, access will be restricted to corporate machines only.
Data leakage – email content filtering tools
  • You will have controls in place to protect our confidential information.
  • Emails that clearly breach our confidentiality requirements will be blocked, e.g. sending of card data, account information and personal data.
  • Our information will not be capable of being sent to webmail accounts.
  • All emails containing our confidential information will be encrypted e.g. Transport Layer Security (TLS)(external link).
  • Any exceptions to these requirements will only be by our approval.
Data loss protection – highly confidential enhanced controls
  • You will have controls in place to protect our highly confidential information.
  • All of our data will only be received, or processed, by people authorised to conduct our work.
  • You will use desktop encrypted email when sending any emails or attachments containing our highly confidential data, which will be encrypted end-to-end between the sender and the recipient.
  • You will ensure that our highly confidential information is not shared via the Internet or stored on a cloud service without our prior approval.
Data leakage – USB and optical media ports
  • USB, optical media ports and other potential mechanisms for portable media will be disabled by default.
  • If a legitimate business case, that we have first approved, requires saving to a USB stick, then:
    • any exceptions will be treated as an incident;
    • authorisation will be provided;
    • a company-issued media only will be used
    • media will be encrypted
    • all files transferred to media will be logged
    • assets will be tracked, i.e. who given to, purpose, when returned
    • all data will be deleted from the USB when no longer required; and
    • at least quarterly reviews will be conducted to check if access is still required.
Business area decommissioning and disposal monitoring You will have a documented policy, and supported process, for the secure destruction of equipment, which includes:
  • frequency of destruction;
  • protection of assets until destruction;
  • a method to validate that the established procedures are carried out; and
  • identifying and rectifying exceptions or material deviations.
Asset management – destruction Where media is securely disposed of:
  • you will provide certificates of destruction, e.g. bags taken by confidential waste, certificates for hardware disposal; and
  • hardware disposed of aligns with the IT asset register.
Technology provider approval of disposal procedures Data will be securely erased or wiped, using industry-approved methods before any equipment is recycled or reused.
Monitoring of media and equipment transportation You will have a documented procedure that includes:
  • methods of transport e.g. tapes, drives, direct link with Data Centre
  • method of encryption, i.e. algorithm and key size, e.g. AES 256
  • requirement for a chain of custody for external/physical media
  • obtain our approval first where our data is to be removed or transferred; and
  • raising an incident for any breaches/exceptions, including notification to relevant suppliers, e.g. loss of hardware.
Data loss protection – hardware in transit Data will be encrypted whilst in transit and in line with data classification.
Data loss protection – hardware in transit Hardware transfers will be logged, including:
  • type of hardware, e.g. server, tape, hard drive;
  • data in transit, e.g. supplier, application(s), data fields;
  • chain of custody; and
  • asset numbers.
Data leakage – mobile bring your own device (BYOD)
  • You will seek our approval before allowing BYODs to be used for our work.
  • You have a documented BYOD policy, and supported process, for:
    • restricting our information from being copied from a protected environment to the personal device;
    • authenticating BYODs before allowing access to our internal network;
    • enforcing anti-malware on BYOD;
    • enforcing encryption of data on BYOD; and
    • what applications are allowed to send, receive, process, and store our data.
Data loss protection – incident management For regular data transfers (including to cloud-based systems), you will record:
  • what data is being transferred;
  • from, and to where the data went;
  • how data was transferred;
  • reasons for the transfer;
  • what controls were used (i.e. encryption); and
  • all required approvals, including from us.
Data transfer agreements
  • You will have agreements in place with your third parties to ensure they adhere to your information, security, and privacy policies.
  • You will raise, as an incident, any data transfers that did not adhere to our classification rules or your data transfer procedures.
Protection of cryptographic keys monitoring You will have a documented policy, supported by the process, for cryptography/encryption that includes:
  • key lifecycle (generation, storage, transfer, usage, revocation, expiration, renewal, archival);
  • ownership with appropriate key custodian declaration;
  • how unique keys are generated, e.g. in software or in hardware security modules (HSM) and implemented, i.e. per client/system/ application;
  • HSMs that are certified for verified random numbers;
  • generators to create random keys in line with FIPS140 or FIPS186;
  • storage of cryptographic keys separately from virtual images and information assets (e.g. in an HSM certified to FIPS140-2);
  • segregation of HSMs and other cryptographic material;
  • backups;
  • the storage process for keys that are held in clear (e.g. written on paper or component held in smart cards);
  • inventory list that includes key owners, key/certificate list, algorithms, key length;
  • schedule for key renewal/rotation;
  • incident plan for all keys; and
  • which industry standards are applicable.
Network diagrams Network diagrams will be:
  • documented with accurate and up-to-date diagrams, e.g. after any change;
  • reviewed at least annually;
  • comprehensive and include all systems;
  • supported by documented control requirements and procedures; and
  • for key systems, on appropriate network segments.
Network connections – external connections To prevent data security breaches, external connections to our network will:
  • first have our approval, be documented (including purpose, approvals, and business justification);
  • be subject to periodic (at least 6 monthly) review, which should include checking for any unapproved external connections;
  • be routed through a firewall;
  • be designed and configured to ensure end-to-end protection of sensitive data in transit;
  • restrict permitted traffic to only required ports, protocols, source, and destination addresses;
  • apply the 'default deny' principle (i.e. any traffic that is not explicitly allowed must be blocked); and
  • not create a bridge between networks of different trust (i.e. production & corporate, public and private, etc.).
Network connections – rulesets Rulesets and configurations for firewalls and other security-enforcing network devices will be verified and approved (i.e. documented change request) and reviewed and updated regularly (at least 6 months).
Wireless connectivity Any wireless access to networks within the scope of the assessment will be secure by design and in operation, including:
  • having a documented design/policy/configuration;
  • enforcing appropriate authorisation; and
  • not permitting known weak or insecure authentication or encryption protocols.
Wireless separation Wireless networking that is not intended to permit access to in-scope networks will have robust separation (physical or virtual) from the in-scope networks.
Network security events and alerts Security-related network events from all relevant sources (including Firewalls, IPS/IDS, WAFs, Remote Access Gateways, MDMs, etc.) will be captured and subject to logging, monitoring, and alerting.
System configuration – builds All infrastructure (including network devices, servers, and end-user devices) will be built, hardened, and maintained according to a documented standard, which is informed by vendor/industry good practice to include:
  • disabling all insecure and unnecessary applications, services, and protocols;
  • changing default passwords;
  • removal of administrative rights;
  • installing most recent patches and updates upon the first build; and
  • installing required security software i.e. anti-virus.
System configuration – monitoring All infrastructure endpoints (including servers and end-user devices) will be monitored to ensure ongoing compliance to build and hardening standards, including:
  • up-to-date installs/patches;
  • use or adoption of unsanctioned cloud services or shadow IT
  • exceptions that are investigated and remediated; and
  • circumvention of policies as enforced by current standards.
Intrusion detection/prevention – tools Intrusion detection or prevention tools will be in place at all appropriate locations on your network. This is to analyse all inbound network traffic to identify and stop (or alert on) any possible incidents, imminent threats or violations, including any arising from unauthorised network connections.
Connection authentication Your internal network will be protected against the connection of rogue/unauthorised devices.
Distributed denial of service (DDoS) – contract You will have a DDoS service contract/specification, including any supporting documentation, for the systems or environments you will use when providing services to us. This is particularly important where those systems or environments are internet accessible or provide communications critical in the service you provide to us.
Distributed denial of service (DDoS) – solution In addition to the requirement directly above, the DDoS solution you have will provide:
  • an adequately scaled DDOS solution (e.g. sizing for peak malicious traffic) allowing them to survive the initial surge of attack traffic, prior to mitigation being put in place;
  • dynamic scrubbing capabilities to filter out malicious traffic;
  • built in protection mechanisms (e.g. ACL restrictions on specific traffic types);
  • active monitoring for DDoS attacks (e.g. traffic patterns/behaviour analysis); and
  • the ability to capture samples of malicious traffic for forensic analysis internally and share them with our cyber experts.
Distributed denial of service (DDoS) – incidents DDoS alerts are security events and you will manage these accordingly, i.e. monitored, analysed, raised as an incident and subject to an appropriate response (including DDoS mitigation service invocation, where necessary).
Vulnerabilities – automated scanning You will have a documented policy, supported by a process, for proactively identifying and managing vulnerabilities in your systems and environments. This includes:
  • technical controls to detect (or prevent) the unauthorised installation of software;
  • regular (at least quarterly) vulnerability scans on internal and external facing infrastructure and systems;
  • vulnerability scans that include scanning of any virtualisation technologies being used, e.g. virtualization aware;
  • management of vulnerabilities e.g. assessment using risk management process and remediation using IT change management process; and
  • continued awareness of external security threat alerts and how the relevant intelligence is acted on.
Service and application security testing monitoring You will have a documented penetration test policy, with a supported process, requiring that:
  • all in-scope environments and systems are tested at least annually (including following any major change) by a competent and independent security testing function;
  • findings from penetration testing are recorded and treated as risks, and prioritised and tracked through to remediation in line with risk management processes; and
  • where not being remediated, any findings affecting the service you provide to us will follow the risk management process (including notification us where these are material).
Vulnerabilities – scope Penetration tests are designed and scoped by competent persons who will have been provided with sufficient information about the system(s)/environment(s) to ensure that applicable types of vulnerabilities are tested for and that any technical limitations to the testing are understood.
Vulnerabilities – recording and management
  • Vulnerabilities identified from any source will be appropriately managed and recorded to include:
    • a description of the vulnerability;
    • what system(s) and/or environment(s) are affected;
    • the inherent risk;
    • the assessed risk (likelihood & Impact) to the business; and
    • the remediation plan, status, and deadline (with priority aligned to risk).
  • Where not being remediated, any findings that may directly or indirectly affect the service you provide to us will follow the risk management process, including notifying us when these are material.
Vulnerability and patch management monitoring Patches will be implemented across the network in accordance with documented procedures, and include:
  • rating and prioritising patches according to their severity and business risk;
  • deployment timeframes for different priorities of a patch exception process, e.g. for legacy systems management of exceptions, i.e. tracked/monitored/approved/escalated; and
  • alignment with change policy.
Patch management Patching compliance will be monitored, reported, and reviewed including:
  • how many (%) machines and types of machines are not patched;
  • the reasons for any exceptions; and
  • how exceptions are managed.
Change management You will have an established change management process that ensures:
  • each change is approved by an appropriate authority;
  • the approval authority is the correct authoriser based on the established procedures;
  • any potential for the approval authority to have a conflict of interest is addressed;
  • emergency changes are documented and are subject to fast-track approval from an appropriate authority;
  • and a post-implementation review is carried out.
Malware monitoring You will have a documented policy and procedure in place for malware protection that includes a requirement that:
  • all anti-malware tools are kept up to date (i.e. signature updates to be deployed within 24 hrs. of release);
  • anti-malware is installed on all systems and devices;
  • failed updates are identified and immediately remediated; and
  • virus containment plans/procedures are in place to prevent the spread of viral outbreaks.
Anti-malware Technical solutions will be implemented, maintained, and monitored as per malware policy/procedures, and all malware detection events are be investigated as potential incidents.
Software development life cycle (SDLC) – policy You will have a documented software development life cycle, demonstrating methodology that includes:
  • showing that you support secure by design and good security practices, e.g. Open Web Application Security (OWASP);
  • development, secure by design/in line with OWASP-approved systems development methodology;
  • testing, code and application/penetration testing; and
  • implementation processes and release management - content version controls and strict processes for the migration of source code from one environment to another.
Software development life cycle – implementation You will have secure SDLC measures in place that:
  • prevent manual or systematic processing errors or corruption of data through input and output integrity routines (i.e., reconciliation and edit checks such as MD5/SHA checksums) that are implemented for application interfaces and databases; and
  • combine binaries on your premises, where only the source code artefacts are sent to any host, e.g. cloud, provider.
Software development life cycle – training Your developers will be trained on 'secure by design' approaches that include OWASP and secure software development lifecycle.
Segregation of production and non-production environments
  • You will have documented policies, supported by processes and procedures, that protect production and non-production environments from unauthorised changes and access.
  • These policies will include the following requirements:
    • current system environments are documented;
    • development/test environments are segregated from production environments;
    • developers/system administrators have separate accounts with different user IDs, e.g. UserID; test_UserID; dev_UserID;
    • permissions/access to non-production environments enforce user access controls commensurate with the environment, such as least privilege and support of segregation of duties;
    • change to code in production is prohibited (except break-glass);
    • there are break glass procedures (in line with change management) for developers to access the production environment (i.e. overriding the segregation of duties requirement); and
    • live data must is not used within any test environment;
    • you get our approval before you use any live data if that data must be used in any tests. (Note: you will need to show us evidence that the controls you have within your test environment are commensurate with those in the production environment).
Quality assurance – standards
  • You will have a systems development quality assurance methodology that supports data security standards that include confidentiality, integrity, and availability.
  • Any checks or code analysis will be carried out by an appropriate person at an appropriate level.
  • You will consider all potential conflicts of interest.
  • You will consider external guidance, e.g. OWASP 10 attributes and NIST.
Quality assurance – review All source code:
  • will be checked prior to implementation or being published.
  • cannot be tampered with by the author or anyone else after it has been reviewed.
  • any bugs and security vulnerabilities will be triaged and remedied.
  • all debugging and test code elements will be removed from released software versions.
PCI DSS compliance

If you: 

  • store, process, or transmit cardholder data or sensitive authentication data on our behalf; or
  • if your software or technology solution interfaces with systems of ours that store, process, or transmit this data, 

Then you must be PCI-DSS compliant to at least level 2.

You will show us, at any time upon our request, necessary evidence to verify your compliance with PCI-DSS, including your most recent attestation of compliance with the Payment Card Industry Security Standards Council.
Cloud computing policy and approval You will have a documented cloud computing policy that:
  • is reviewed at least annually or following any changes to the service;
  • identifies the roles and responsibilities of individuals or teams in respect of developing, reviewing, maintaining, and applying cloud computing policy, which represents established practice.
  • is agreed and signed off by management, who affirm that they all acknowledge and understand the risk and will treat risk exposures in line with contractual, legal, and regulatory requirements.
Cloud computing policy content Your cloud computing policy will contain at least the following:
  • a requirement that all business use of cloud computing services, and the data to be stored or processed using those services, must be formally approved by the organisation's principal security officer (e.g. CSO/CIO) or with their delegated authority;
  • the requirement for an established clear understanding of the roles and responsibilities of who operates controls in the cloud (1st party, vendor, 4th party etc);
  • for any cloud services that require users to agree to terms of service, such agreements must be reviewed and approved by the CSO/CIO or with their delegated authority;
  • the requirement that the use of such services must comply with your acceptable use policy/computer usage policy/internet usage policy/BYOD policy, or similar;
  • the requirement that the use of such services must comply with all laws and regulations governing the handling of personally identifiable information and Personal Information (as defined by the Privacy Act 2020), financial data or any other data that we, or you, own or collect;
  • a restriction that personal cloud services accounts may not be used for the storage, manipulation or exchange of company-related communications or company-owned data; and
  • that any use of Cloud is subject to all appropriate security controls that you have in place.
Cloud computing service and deployment framework You will have an established cloud computing (including cloud security) service and deployment approach (framework) that addresses at least the following:
  • how any use of cloud is identified and managed;
  • the ownership, update, and approval of cloud requirements, policies, and procedures;
  • identification of the service models being used (SaaS, PaaS, IaaS);
  • identification of the deployment models being used (e.g. Private, Public, Community, Hybrid);
  • assurances for compliance with legal and regulatory requirements;
  • ensuring required security controls and responsibilities are established and maintained, and subject to periodic review and testing;
  • data residency of cloud security services; and
  • the management and control of any subcontractors hosting, storing and processing our data as part of cloud deployment services.
Cloud computing service and deployment framework You will engage your use of cloud service in accordance with your established cloud computing (including cloud security) service and deployment approach (framework).
Cloud user training and awareness For providers of cloud services where we are a tenant, you will have a formal, role-based security awareness training program for cloud-related access and data management issues for all persons with access to tenant data.
Physical security – policy You will have a documented security policy, with supported processes, that:
  • nominates an individual or a specific role that is accountable for physical security;
  • puts measures in place to prevent and detect the unauthorised removal of systems and devices that store or process our data;
  • controls access to your building(s), specifically for buildings from which services are provided to us or where our data is stored; and
  • is aligned with your joiners/movers/leavers process.
Physical security – training You will regularly (at least yearly) train all employees and contractors on security awareness and their respective responsibilities.
Physical security – review You will perform an annual review of your security standards and compliance on all your premises where our information is stored.
Physical security – access You will annually review who has physical access to your building. For sensitive or restricted areas of your building, you will review this at least quarterly.
Physical security – controls (access control)
  • You will have physical security controls in place, such as physical barriers to protect against unauthorised access and access control mechanisms for entering the building (i.e. electronic access, security guards, etc.)
  • Sensitive rooms (e.g. server rooms) and those specific to store or process our data will have additional access controls that are proactively monitored.
Physical security – controls (access logs) You will retain all access logs for at least 12 months.
Physical security – controls (visitors) You will have a visitor process in place where all visitors are booked in and out of the facility, allocated a visitor pass, and supervised at all times.
Physical security – controls (CCTV)
  • You will have CCTV coverage and monitoring in place at the entry and exit points of any building and secure areas.
  • All images will be retained for at least 30 days or 90 days for where customer data is stored (including card data).
  • The location of the CCTV recording equipment will be physically protected.
Physical security – controls (intrusion detection)
  • You will have an intrusion detection system in place that is active on all doors and windows where our data is held or processed.
  • This system will be monitored 24/7, 365 days a year.
Physical security – controls (electronic security) You will have electronic perimeter access controls at every access/egress point to your building that run 24/7 and secure all exit doors.
Physical security – controls (maintenance) You will maintain all electronic security systems through a certified authority.
Physical security – incidents You will investigate all breaches of your security defences, follow your incident management procedures and report all relevant breaches to us without delay.