Our policies for you
You might have already picked up that we are not fans of doing work for work’s sake, so you might be surprised to see we put so much effort into making our policies understandable and clear.
We do this because we fully believe they are important. These policies help you understand how much we value your trust in us to keep your information safe and secure.
Security and data
Our security statement
This is really our security policy. It provides our approaches to manage and keep your information secure.
If you are looking for our guiding security approach, this is a great place to start.
Acceptable use
This outlines what you agree to when using our software.
Basically, as the agreement says, don’t be dumb and try to use it for mean things. If you are unsure what you might be permitted to do download this, but really, acceptable use is about being fair and reasonable and not malicious – the rest is just detail.
Data collection and privacy
Needing information on how we collect data and how we keep that information private? This is the policy for that.
TL:DR – Basically we collect data on a bare minimum required to get the job done approach.
Our standard agreement of use
This is our standard agreement for our customers. We have tried to ensure our terms are clear and understandable, however what we strive for is to ensure you will never even look at these because our partnership will be strong and valued by both of us.
Individual user terms of use
This outlines what your staff agree to when using our software. We have tried to keep it simple and clear. It doesn’t conflict with your agreement but is a good thing to share with anyone that has concerns where the overall agreement might be more than they need.
Plus, let’s be honest, we need to have one of these to comply with app store requirements, so we can give you mobile apps for your workforce.
Service Level Agreement
Payroll doesn’t have the ability to have excuses. People need to get paid. We think vendors to local government shouldn’t have excuses for providing support either, so we don’t.
We take responsibility for our product, patches, testing, and support. That means if you need support, we are here to give it regardless of any ‘level’ agreement.
FAPQ (aka Frequently Asked Policy Questions)
Whats the story with retaining and deleting data?
Data is important and valuable (that’s why you get to use those social media platforms without paying a subscription), and we recognise that. Our approach is to retain collected information only for as long as necessary to provide you with your requested service.
The data we store will be protected within commercially acceptable means to prevent loss, theft, unauthorized access, disclosure, copying, use, or modification.
If your data, including that of your organisation, is no longer needed, then your data will be removed. This includes where your organisation no longer needs our services or has requested that your data be removed.
Removing your data (or your organisation’s) includes deleting all data stored on our software and supporting platforms. We will also take all reasonable efforts to remove all data from supporting services, including email and messaging. We will take all reasonable efforts to also remove data from backup, logs, and other data touchpoints. The only exception to this is where we are unable to remove your data due to legal requirements.
For more information, check out our data policies.
Who gets to see data?
Great question and a little cloudy so lets clear the skies as much as we can.
In your organisation…
We may share the information with your organisations responsible officers with a ‘need-to-know’ approach to enable them in the performance of their duties. We will check for approval from your organisation owner before granting additional data access rights to any staff within your organisation.
Within our organisation…
We manage access to data through a ‘need-to-know’ role management principle. This means only staff that need access to your data to provide a service to you will have access to that data, such as responding to support tickets or requests. We do not use real data for testing or demoing even within our team.
Data and information is only used to help us help you. Raw data logs are retained temporarily as required for security and site management purposes only. We do not share this information with other parties or organisations.
Note: We don’t share any personally identifying information publicly or with third parties, except when required to by law. Our app may link to external sites that are not operated by us. Please be aware that we have no control over the content and practices of these sites and cannot accept responsibility or liability for their respective privacy policies.
Whats the story with backing up data (AKA how do we do disaster recovery)?
Just in case you missed our views on this, we believe your data is your data, and that means we should ensure we manage it, even if there is a disaster. If you need data managed in a particular way or need help to build a BCP or DRP (or don’t know what a BCP or DRP is), then just reach out; otherwise, read on. Remember, we manage records of work – point in time back-ups are not really needed as all history exists. Our log management is managed separately:
1. How often do we perform backups?
It depends a little on the backup we are doing, but in general, for:
- Frequency: Continuous (real-time)
- Duration: Instant
- Method: Stored in S3 with Versioning enabled
- Architecture: Our EC2 instances operate within Auto Scaling Groups (ASG) and are designed to be stateless using AMI/Packer/Ansible, so theoretically no need to back up
- Backup necessity: While dedicated EC2 backups aren’t typically required due to our stateless design, we maintain AWS Backup Service as a precautionary measure
- Automated Backup by Aurora RDS: Daily
- Method: Automated via Aurora’s built-in backup and AWS Backup Service
- DR: Auto-create snapshot every 6 hours and copy to DR region (ready for restore)
- Retention: Indefinite (no dedicated retention rules set in lifecycle policy)
- Cross-region: Auto-synced from Sydney to DR/Melbourne region
- Retention: 7 days
- Method: AWS Backup Service (though rarely needed due to stateless design)
- Note: We use AMI/Packer/Ansible to keep EC2 instances stateless
- Automated backups: 30 days retention
- AWS Backup Service: 7 days retention
- DR snapshots: Daily snapshots copied to DR region
Yes, absolutely.
EC2 Instances: Restoration is rarely required due to stateless architecture, but possible within a 7-day window
Database:
- Proven capability – We’ve successfully restored multiple times for database upgrades
- DR ready – 6-hourly snapshots in DR region, ready to create new RDS clusters
- Point-in-time recovery available up to 30 days
What about the elementTIME uptime service level?
Funnily enough, we have an opinion on this as well.
We think target uptimes are an out-of-date metric often supplied by vendors wanting to sound impressive but give themselves an excuse when needed.
We believe that when you need a system, it should be available, whether it is inside or outside of some random metric. We don’t believe in giving ourselves a cop out target to allow for failure. Our uptime metric is to be available when our clients need us available – that means there should never be unplanned outages that impact operational needs.
Planned outages are rare (we have had no planned or unplanned outages during operational hours in the last 18 months), but may occur in consultation with the relevant organisation and with a complete operation mitigation plan in place.
But if, after all tha,t you still need a metric to tick a box on a form, then say greater than 99%. PS, between us, we will work on the ‘Always’.
Free up your people to focus on the important stuff
Automate and streamline your payroll process so your staff can focus on doing great things that matter for your community.