Document 4 FINAL.pdf

IN-CONFIDENCE
ICT Shared Capabilities
Marketplace
Payroll Enterprise Software
Provider Hosted
Security Risk Assessment
Report
under the Official Information Act 1982
Issued by
Digital Public Services Branch
Released

under the Official Information Act 1982
Released

IN-CONFIDENCE
Glossary of Terms
Availability
Ensuring  that  authorised  users  have  timely  and  reliable  access  to
information.
API
A  set  of  functions  and  procedures  allowing  the  creation  of
applications that access the features or data of an operating system,
application, or other service.
Confidentiality
Ensuring that only authorised users can access information.
Consequence
The outcome of an event. The outcome can be positive or negative.
However, in the context of information security it is usually negative.
Control
A  risk  treatment  implemented  to  reduce  the  likelihood  and/or
impact of a risk.
Gross Risk
The risk without any risk treatment applied.
Impact
See Consequence.
Information Security
Ensures that information is protected against unauthorised access
or  disclosure  users  (confidentiality),  unauthorised  or  improper
modification  (integrity)  and  can  be  accessed  when  required
(availability).
Integrity
Ensuring  the  accuracy  and  completeness  of  information  and
information processing methods.
Likelihood
See Probability.
Probability
The chance of an event occurring.
Recovery Point Objective
The earliest point time that is acceptable to recover data from. The
(RPO)
RPO effectively specifies the amount of data loss that is acceptable
to the business.
Recovery Time Objective
The  amount  of  time  allowed  for  the  recovery  of  an  information
(RTO)
system  or  service  after  a  disaster  event  has  occurred.  The  RTO
effectively  specifies  the  amount  of  time  that  is  acceptable  to  the
business to be without the system.
Residual Risk
The risk remaining after the risk treatment has been applied.
Risk
The effect of uncertainty on the business objectives. The effect can
be  positive  or  negative.  However,  in  the  context  of  information
under the Official Information Act 1982
security it is usually negative.
Risk Appetite
The  amount  of  risk  that  the  organisation  is  willing  to  accept  in
pursuit of its objectives.
Risk Owner
A person or entity with the accountability and authority to manage
a  risk.  Usually,  the  business  owner  of  the  information  system  or
service.
Stakeholder
A person or organisation that can affect, be affected by, or perceive
Released
themselves to be affected by a risk eventuating.
Threat
A potential cause of a risk.
Vulnerability
A  weakness  in  an  information  system  or  service  that  can  be
exploited by a threat.

Payroll Enterprise Software (SaaS) SRA
IN-CONFIDENCE
Page 4 of 49

IN-CONFIDENCE
Contents

Document control
2
Revision History
2
Glossary of Terms
4
Executive Summary
6
Introduction
6
Key Risks
6
Gross Risk Position
9
Key Recommendations
10
Residual Risk Positions
12
Business Context
14
Business Processes Supported
14
Information Classification
17
Users and Stakeholders
19
Legislation, Policy, and Guidelines
20
Technical Context
21
Security Requirements
23
Out-of-Scope
25
Detailed Risks
26
Controls Catalogue
38
Appendix A – Consulted Agencies and Suppliers
44
Appendix B – Project Overview
45
Appendix C – Risk Assessment Guidelines
47
Rating Risk
47
Likelihood (Probability) Assessment
47
Impact (Consequences) Assessment
47

under the Official Information Act 1982
Released
Payroll Enterprise Software (SaaS) SRA
IN-CONFIDENCE
Page 5 of 49

IN-CONFIDENCE
Executive Summary
Introduction
Payroll is a large, important, and complex part of an agency. To effectively run payroll services, the
software used must integrate with many different systems. All these systems combined perform key
business functions ranging from payroll, time and attendance, award interpretation, rostering, human
resources, workforce management, self-service, and data management.
In the Marketplace, Payroll itself is made up of two channels:
• Managed  Services,  which  includes  both  software  and  a  range  of  associated  business  and
supporting services; and
• Enterprise Software, which includes the software.
The Marketplace Payroll Enterprise Software catalogue includes both provider-hosted (or Software-
as-a-Service, SaaS) and agency-hosted products.
This report includes the findings for the information security  Risk Assessment for a provider-hosted
Payroll  Enterprise  Software  product  used  by  Consuming  Agencies  (CAs).  There  will  be  multiple
suppliers (or Providers) that will provide this product, and each CA will have their own unique context
and risk appetite. Therefore, this report contains generic findings and the intent is that each CA will
review them using their own risk management framework. This Risk Assessment also only considers
the  context  that  the  data  stored,  transmitted,  or  processed  by  these  products  is  classified  as  IN-
CONFIDENCE or lower. If a CA stores, transmits, or processes data with a higher classification, they will
need to re-assess these risks using their own information classification policy and risk management
framework.
The  details  of  the  Marketplace  structure  and  security  risk  assurance  framework  can  be  found  in
Appendix B.
The  Risk  Assessment  performed  followed  the  Government  Chief  Information  Officer’s  (GCIO)  Risk
Assessment  process,  which  is  based  on  the  AS/NZS  ISO  31000:2009  and  ISO/IEC  27005:2011  risk
management standards.
under the Official Information Act 1982
9(2)(k)
Released
Payroll Enterprise Software (SaaS) SRA
IN-CONFIDENCE
Page 6 of 49

IN-CONFIDENCE
9(2)(k)
under the Official Information Act 1982
Released
Payroll Enterprise Software (SaaS) SRA
IN-CONFIDENCE
Page 7 of 49

IN-CONFIDENCE
9(2)(k)
under the Official Information Act 1982
Released
Payroll Enterprise Software (SaaS) SRA
IN-CONFIDENCE
Page 8 of 49

IN-CONFIDENCE
Gross Risk Position
Table 1 illustrates the rating of each risk without any controls in place.
Table 1 – Gross Risk Ratings
9(2)(k)
under the Official Information Act 1982
Released
Payroll Enterprise Software (SaaS) SRA
IN-CONFIDENCE
Page 9 of 49

IN-CONFIDENCE
Key Recommendations
The Risk Assessment included key controls that if implemented, helps to address the identified risks.
A Controls Validation Plan (CVP) was also developed to specify the recommended controls outlined in
the Risk Assessment.

9(2)(k)
To mitigate and manage the identified gross risks rated as
the following key recommendations should be undertaken:
1.  Provider and Vendor Due Diligence
The CA will be unable to control how the Provider manages the components of the software that
are outside of the CA’s control. The Provider is also unlikely to share any details about how they
secure or manage those components as this is confidential information for a likely multi-tenancy
environment. If the information were used against the Provider, it could result in risk events that
affect more of their customers than just the CA.

Although  the  CA  will  not  be  able  to  perform  a  full  audit  of  the  software,  they  can  obtain
information on what controls the software does provide and if the CA can use those controls to
manage their own risks. For example, an important control for the CA to configure is role-based
(and organisation-based for multi-agency payroll) access controls. If the Provider and software
does not provide enough granular levels of configurations, it will not be possible  for the CA to
implement this control which would lead to higher risks.

For the controls listed in this report and the CVP, the CA should verify which controls are available
to  be  configured  (which  can  be  verified  by  the  Provider)  before  attempting  to  implement  the
controls  themselves.  This  includes  controls  such  as:  role-based  access  controls,  organisation-
based access controls, separation of duties, least privilege, logging and auditing, information and
security  incident  management,  data  backups,  encryption  in-transit,  identity  management,  and
unused features.

2.  Access Management and Controls
There are high risks related to the misconfiguration by CA users or unauthorised access to CA user
accounts. These risk events can lead to various impacts due to the value of data in the system.
One  of  the  most  important  set  of  controls  for  the  CA  to  implement  will  be  strong  access
management and controls.

under the Official Information Act 1982
This  includes  controlling  how  users  authenticate  to  reduce  the  likelihood  of  someone  gaining
unauthorised access to an account. It also includes making sure there are granular enough roles
and permissions so the CA can properly separate responsibilities and follow the principle of least
privilege.

3.  Logging and Incident Response
Since the higher risks faced by a CA are related to misconfiguration or unauthorised access, it will
Released
be important to have detective controls in place in the event the access controls (preventative
controls) fail.

Logging and auditing will depend on what is available from the Provider and the software, and will
be a critical detection point for CA. These detection points will need to then feed into a security
Payroll Enterprise Software (SaaS) SRA
IN-CONFIDENCE
Page 10 of 49

IN-CONFIDENCE
incident management process. That way if risk events do occur, the CA can respond quickly and
effectively to minimise the impact.

4.  Additional Assessments
This  Risk  Assessment  is  expected  to  cover  most  of  the  use  cases  for  a  CA  that  wishes  to  use
Provider-hosted payroll software. However, there will be a few edge cases that might apply that
can have large impacts to security risk. This includes edge cases related to:
•  Initial migration from the previous payroll system;
•  Overseas legislation;
•  Use or storage of Classification Removed data; and
•  Limitations of software hosted overseas (i.e., jurisdictional, performance, operational risks).

A  CA  should  consider  if  these  edge  cases  apply  to  their  context  and  perform  additional  risk  or
assessment work to fully understand how this context affects these risks.

under the Official Information Act 1982
Released
Payroll Enterprise Software (SaaS) SRA
IN-CONFIDENCE
Page 11 of 49

IN-CONFIDENCE
Residual Risk Positions
Table 2 below illustrates the expected residual rating of each of the risks if all the recommended
Provider controls are implemented and appropriately configured and managed.
Table 2 – Provider Residual Risk Ratings
9(2)(k)
under the Official Information Act 1982
Released
Payroll Enterprise Software (SaaS) SRA
IN-CONFIDENCE
Page 12 of 49

IN-CONFIDENCE

Table 3 below illustrates the expected residual rating of each of the risks if all the recommended
Consuming Agency controls are implemented and appropriately configured and managed.
Table 3 – Consuming Agency Residual Risk Ratings

9(2)(k)
under the Official Information Act 1982
Released
Payroll Enterprise Software (SaaS) SRA
IN-CONFIDENCE
Page 13 of 49

IN-CONFIDENCE
Business Context
This section provides an overview of the generic business context for the Payroll Enterprise Software
(Provider-hosted) products that are in scope of this generic information security Risk Assessment.
9(2)(k)
under the Official Information Act 1982
Released

Payroll Enterprise Software (SaaS) SRA
IN-CONFIDENCE
Page 14 of 49

9(2)(k)
Pre-payroll Services Processes
Recording of pay data involves many factors:
•
Salary or rostered wages;
•
Schedules or work patterns (default, or custom); and
•
Pay rules (award interpretation, or deductions and allowances).
Salary
under the Official Information Act 1982
Salaried employees have a pattern set in their work profiles that determines how pay is calculated,
and this would be configured and set in the payroll system. There is a default pattern that represents
a common, standard salaried employee (such as Monday to Friday, 8AM to 4PM).
This pattern can be changed and is often happens due to different pattern terms in the salaried
employee’s individual agreement or collective agreement, change in part-time or full-time status.
Released
Rostering / Time and Attendance
Payees paid according to a roster can be full-time, part-time, or casual employees. If a payee is on
rostered wages, the time that they are paid for is based on either rostering (hours recorded in
advance) or a time and attendance (hours recorded already worked). Either could be performed:
•
Manually, such as using spreadsheets and entering data into a system; or
Payroll Enterprise Software (SaaS) SRA
IN-CONFIDENCE
Page 15 of 49

IN-CONFIDENCE
•
Using a system, either within a separate rostering system or within the payroll software (as an
add-on feature).
There are common controls and processes followed to confirm the integrity of the hours before the
payroll process kicks off:
•
Default schedules and configurations – These are set in the rostering or time and attendance
systems, and make sure the pay is correct and complies with the Holidays Act;
•
Approval  flows  –  Hours  recorded  would  go  through  an  approval  flow  and  the  approvers
required  would  depend  on  either:  delegation  matrix,  collective  agreement,  individual
agreements, or multi-employer agreements; and
•
Data integrity reports – These can be run in the payroll systems to confirm the pay calculated
is accurate, complete, and reliable.
Pay Rules
Last  part  of  recording  pay  correctly  involves  pay  rules  and  this  involves  considering  any  award
interpretation, allowances, and deductions that might apply to a specific payee.
Award interpretation involves the translation of worked hours into a paid value based off rules and
regulatory requirements set in the system. This can include allowances, overtime, and penalties. The
rules and requirements are configured in either:
•
The separate rostering systems; or
•
Within the payroll software (as an add-on feature)
Common deductions that need to be configured before payroll is run includes:
•
Employment or contract status;
•
Salary sacrifice (or a donation of part of their salary to a charity);
•
Kiwisaver or superannuation contributions;
•
Inland Revenue Department or Ministry of Justice fines;
•
Student loan payments;
•
Any other changes agreed (such as overpayments, payment of leave up-front); and
•
Payroll tax.
Payroll Processes
The payroll process for each CA will vary, but there are some common steps taken including:
under the Official Information Act 1982
•
Data integrity reporting and validation;
•
Trial pay runs;
•
Calculation of pay;
•
Final pay run and generation of pay, bank, and other third-party files; and
•
Repeat of process for multiple pay runs (i.e. multi-agency payroll).
Pay Calculations
Pay calculation m
Released  ay start off with the data that is imported in from other systems (9(2)(k)

9(2)(k)
r it will start off with data based off the profile and rules that the
payee is set up with in the payroll system.
These calculations are consistent across agencies due to required compliance with the Holidays Act,
however they still need  to be  configured within the system. The CA can alternatively follow the
Payroll Enterprise Software (SaaS) SRA
IN-CONFIDENCE
Page 16 of 49

IN-CONFIDENCE
common  process  model,  which  helps  the  CA  make  sure  the  payroll  rules  configured  meet  good
practice and legislative requirements.
Pay Runs
A CA may administer multiple pay runs before pay is finalised. It may involve a trial run, which checks
if  the  CA  is  under  or  overpaying.  Multiple  checks  take  place  including  checking  number  of  payees
compared to number of employees, comparing of pay data to previous pay runs. These results are
also needed for audit evidence.
When the final run is administered, multiple files will be generated and may include (but is not limited
to):
•
Bank files – which are transferred to the CA’s bank for payment to payees;
•
IRD files – which are transferred to IRD for tax and other compliance;
•
Payees pay information – which includes a summary of their pay, allowances, and deductions;
•
3rd party files – for uploading of pay data into other systems the CA may use (such as financial
management or accounting systems), or to other 3rd parties that deductions were made for
(such as Ministry of Justice); and
•
Union files – which includes a summary of union fees that have been paid.
These files may be manually transferred (by manually uploading the files to the other system) or there
may be an integration or file transfer system used by the CA.
For CA that look after multiple agencies’ payroll, this process would repeat for each agency they look
after.
Post-payroll and Ongoing Processes
After the payroll run is complete, a CA will perform:
•
Accounting and recording of the pay run; and
•
Reporting and sharing of reports with groups within the CA or agencies they administer payroll
for.
There will also be ongoing services that take place outside of the payroll run, such as:
•
Software data management (such as configuration management of profiles, pay  rules, and
under the Official Information Act 1982
other payroll-related configurations, access management, and data management);
•
Integration  management  (such  as  Rostering,  Time  and  Attendance,  HR,  and  bank  system
integration);
•
Identity Provider integration (for authentication to the system);
•
Software,  infrastructure,  and  hardware  management  (which  in  the  scope  of  this  report  is
managed by the SaaS Provider); or
•
Supporting procedural controls  (such as incident response, disaster recovery, and  business
Released
continuity).
Information Classification
The  security  classification  of  the  information  that  will  be  stored,  processed,  or  transmitted  by  the
payroll software has been evaluated as IN-CONFIDENCE and below. This is because while the payroll
Payroll Enterprise Software (SaaS) SRA
IN-CONFIDENCE
Page 17 of 49

IN-CONFIDENCE
software and business processes contain personal information, this data would not cause an impact
to diplomatic, economic wellbeing, safety, or operational effectiveness of New Zealand.

There is a risk that the payroll software may store Classification Remove information. The most common situations
include:
•  Data  or  documents  uploaded  related  to  leave  taken  that  involves  domestic  violence,
vulnerable children, or health information.

If CAs wish to consume the software for information classified to Classification Removed  CAs will need
to comply and confirm with controls detailed in the Protective Security Requirements (PSR).

under the Official Information Act 1982
Released
Payroll Enterprise Software (SaaS) SRA
IN-CONFIDENCE
Page 18 of 49

under the Official Information Act 1982
Released

IN-CONFIDENCE
Legislation, Policy, and Guidelines
CA must ensure that they can demonstrate compliance with applicable legislation, policies, guidelines,
and any other external requirements when using payroll software.
The following legislation, policy, and guidelines relate specifically to security requirements are
considered relevant to most CAs:
• Protective Security Requirements (PSR); and
• New Zealand Information Security Manual (NZISM v3.4).
The following legislation, policy, and guidelines relate different aspects to the payroll function or the
business processes they support:
• Holidays Act 2003;
• Human Rights Act 1993;
• Privacy Act 2020;
• Income Tax Act 2007;
• Employment Protection Act 1987;
• Live Organ Donors Act 2016;
• Public Records Act 2005;
• Minimum Wage Act 1983;
• Official Information Act 1982;
• Parental Leave and Employment
• KiwiSaver Act 2006;
Protection Act 1987;
• Accident Compensation Act 2001;
• Public Finance Act 1989;
• Child Support Act 1991;
• Student Loan Scheme Act 2011;
• Datacom GSF Specifications;
• Support Workers (Pay Equity)
• Domestic Violence Amendment;
Settlements Act 2017;
• Employment Relations Act 2000;
• Tax Administration (Correction of
• Equal Pay Act 1972;
Errors in Employment Income
• General Disposals Authority 6;
Information) Regulations 2019;
• Health and Safety at Work;
• Tax Administration Act 1994;
• Home and Community Support
• Volunteers Employment Protection
(Payment for Travel Between Clients)
Act 1973; and
Settlement Act 2016;
• Wages Protection Act 1983.
Some CA may provide payroll services to payees who must comply with overseas legislation. There
will be different requirements and impacts if these are not followed and were not considered in the
context of this work. The CA should perform their own assessment when understanding their specific
requirements under any legislation.
under the Official Information Act 1982
Released
Payroll Enterprise Software (SaaS) SRA
IN-CONFIDENCE
Page 20 of 49

9(2)(k)
under the Official Information Act 1982
Released
Payroll Enterprise Software (SaaS) SRA
IN-CONFIDENCE
Page 21 of 49

IN-CONFIDENCE
9(2)(k)
under the Official Information Act 1982
Service Owner and Experts
Each CA will have to use this Risk Assessment and apply it to the specific Provider and payroll software
solution they selected from the Marketplace, and to their own internal risk framework and context.
As part of that, the CA can get support from the following stakeholders:
•
Senior Responsible Officer – or the officer responsible for the use and risk of the software in
Released
their agency;
•
IT Security Manager – or the manager responsible for performing security assurance for the
system;
•
Solution Architect – or the architect responsible for identifying the technical components and
features in the Provider and software chosen; and
Payroll Enterprise Software (SaaS) SRA
IN-CONFIDENCE
Page 22 of 49

IN-CONFIDENCE
•
Payroll and other subject matter experts – or others in the CA who can assist with adjusting
this Risk Assessment in the context of how the system will be used within the CA.
Security Requirements
The security requirements help inform the technical impact of the security risks captured, and the
requirements vary based off the confidentiality, integrity, availability, and privacy requirements of the
data used by the payroll system.
The  exact  security  requirements  will  vary  by  CA  and  will  require  the  CA  to  assess  using  their
framework. In most cases, the impacts across CA will be similar. Those impacts have been defined
below:
Confidentiality and Privacy
The payroll system will store, process, and transmit information that includes Personally Identifiable
Information (PII), and limited Classification Removedinformation that may be included in their leave, allowance, and
deduction requests. This information is considered IN-CONFIDENCE.
There  are  different  ways  this  information’s  confidentiality  or  privacy  could  be  compromised:  an
administrative or system user could accidently or intentionally share data exports, pay files, or reports;
the system could be mis-configured which would allow other system users to see data they shouldn’t
be allowed to see;  a  CA’s account could be inappropriately accessed leading to a data breach; the
Provider  could  have  a  security  incident  relating  to  their  staff  or  the  system  which  leads  to  a  data
breach.
The impact of a confidentiality or privacy incident would vary, and it would depend on the amount of
information involved. If there was a small amount of information involved, the impact to the CA would
be moderate. If there was a large of amount of information, the impact would be significant. It could
result in:
•
Breach  of  laws,  resulting  in  litigation  and  against  the  CA  (and  other  agencies  they  provide
payroll services for);
•
Significant reputational and political damage;
•
Loss of confidence in the security of the software;
•
Significant  ongoing  operational  and  service  delivery  impact  to  the  CA  due  to  incident
investigation and process changes;
•
Significant  financial  impact  due  to  the  need  for  additional  resources  to  assist  with  the
under the Official Information Act 1982
investigation and resolve any issues, and for any litigation fees; and
•
Minister and leadership briefing and updates.
Integrity
The payroll system is a key component of the overall payroll function within a CA. They rely on the
accuracy and integrity of the data in the system for payroll processes as well as supporting business
processing (such as financial reporting and HR).
Released
There are different ways the information’s integrity could be compromised, and most of those events
come down to access controls (including user access and data separation). The impact would also vary
and would depend on the amount of information that was modified. If there was a small amount of
information involved, the impact to the CA  would  be  moderate. If there was a large of amount of
information, the impact would be significant. It could result in:
Payroll Enterprise Software (SaaS) SRA
IN-CONFIDENCE
Page 23 of 49

IN-CONFIDENCE
•
Breach of laws (such as Holidays Act due to incorrectly calculated pay)
•
Significant reputational and political damage;
•
Loss of confidence in the security of the software;
•
Significant ongoing operational and service delivery impact to the CA due to incident
investigation and process changes;
•
Moderate financial impact due to the need for additional resources to assist with the
investigation and resolve any issues, and for any litigation fees; and
•
Minister and leadership briefing and updates.
Availability
Payroll is a regularly occurring process and is heavily relied on by multiple stakeholders (as captured
above under Users and Stakeholders).
There are different ways the availability of the system or the information could be compromised. It
could be unavailable for a short period of time due to a breaking change or misconfiguration, or it
could be unavailable for an extended period due to a prolonged Distributed Denial of Service (DDoS),
Denial of Service (DoS), or security incident with the payroll software and Provider.
If the system were unavailable outside of the pay run part of the process (less busy period), the
impact would be moderate. If the system were unavailable during the pay run part of the process,
the impact would be significant. It could result in:
• The CA standing up an incident response or business continuity team to administer the pay
run without the payroll software;
• Increased operational and service delivery impacts due to manual processing and post-
incident system updates;
• Significant reputational and political damage;
• Financial impact due to additional resources needed to administer manual pay runs; or
• Leadership and Minister briefing and updates.
under the Official Information Act 1982
Released
Payroll Enterprise Software (SaaS) SRA
IN-CONFIDENCE
Page 24 of 49

under the Official Information Act 1982
Released

IN-CONFIDENCE
9(2)(k)
under the Official Information Act 1982
Released
Payroll Enterprise Software (SaaS) SRA
IN-CONFIDENCE
Page 26 of 49

under the Official Information Act 1982
Released

IN-CONFIDENCE
Table 6 – Controls to Risk Mapping
Table 6 shows which controls (that are recommended for both the Provider and CA) are related to
each risk from Table 4.
9(2)(k)
under the Official Information Act 1982
Released
Payroll Enterprise Software (SaaS) SRA
IN CONFIDENCE
Page 43 of 49

under the Official Information Act 1982
Released

IN-CONFIDENCE
Appendix B – Project Overview
Scope
Marketplace is an AoG initiative that enables New Zealand and international businesses offer their
products and services directly to New Zealand government agencies. Marketplace links business with
government,  making  the  procurement  process  easier  for  all.  For  more  details,  please  visit
https://marketplace.govt.nz

The Department of Internal Affairs (DIA), as Government Chief Digital Officer (GCDO), have performed
and completed this Risk Assessment report and Controls Validation Plan (CVP) to support the CAs who
plan to use this Marketplace-listed catalogue service.

The objective was to create a generic Risk Assessment and CVP that would cover most of the security
risks and controls that would apply regardless of Supplier, technology, or specific context. The intent
is that this would set a baseline for the CAs to use and then apply their own internal risk management
frameworks and accredit the service for their own use.

Marketplace has a list of catalogue items and suppliers that are categorised in Tier 1, Tier 2, and Tier
3. The Tier 3 a is lower entry bar for small products and suppliers where, Tier 1 is for enterprise grade
products and applier that requires highest assurance.

For  the  purposes  of  this  work,  it  was  assumed  the  Payroll  Enterprise  Software  (provider-hosted)
product would have a minimum Tier 1 rating.

The minimum Tier rating is based on:
•  Risk profile of the service;
•  Use / delivery of cloud-based tools to deliver Managed Services;
•  Reliance on Agency controls, particularly for people and process controls; and
•  Claims made by the Supplier in the service description.

Tier  3:  Baseline  Index  — Suppliers  respond  to  security  questions  which  can  include  the  Cloud  Risk
Assessment  Tool  (GCIO105).  Assessment  is  based  on  self-assertions  and  not  independent  reviews.
SaaS go through a Confidence and Risk Index (CRI) rating by McAfee MVision.

under the Official Information Act 1982
Tier  2:  Design  and  Control  Analysis  — Suppliers  must  provide  independent  security  assurance
information that Consuming Agencies will be able to review. This can include ISO27001 or SOC2 Type
2  audit  reports,  and  penetration  testing  reports.  This  information  will  be  reviewed  and  confirmed
appropriate by the GCDO before Tier-2 endorsement.

Tier 1: Design and Control  Effectiveness — To obtain this rating, suppliers  must provide additional
information and receive Certification from the GCDO. Certification is based on Risk Assessment and
demonstration of controls effectiveness can be supported from an organisation having ISO 27001 or
Released
SOC2 Certification or going through an audit by an auditor from the SRS panel.
Payroll Enterprise Software (SaaS) SRA
IN CONFIDENCE
Page 45 of 49

IN-CONFIDENCE
Approach
The Risk Assessment followed the GCDO risk framework based on the AS/NZS ISO 31000:2009 and
ISO/IEC  27005:2011  risk  management  standards.  The  assessment  was  conducted  as  a  series  of
workshops and document reviews, including:
•  Consumption of documentation provided by DIA;
•  Identification  of  risks  and  controls  associated  with  the  use  of  provider-hosted  Payroll
Enterprise Software;
•  Development of a Risk Assessment report in draft;
•  Review of risks and ratings through a risk validation workshop; and
•  Issuance of a final Risk Assessment report.
under the Official Information Act 1982
Released
Payroll Enterprise Software (SaaS) SRA
IN CONFIDENCE
Page 46 of 49

under the Official Information Act 1982
Released