Back-up

Data

Method

• SQL Server databases are backed up through Azure Backup.

• Azure Backup uses Geo-redundant storage.

• Geo-redundant storage (GRS) copies data synchronously three times within a single physical location in the primary region.

• Data is then copied asynchronously to a single physical location in a (geographically different) secondary region.

• RDS databases backed up through AWS Backup service

• AWS Backup allows us to define a central data protection policy (called a backup plan)

• AWS Backup automates the creation of backups and stores those backups in the designated encrypted backup vault.

Databases are backed up through Microsoft Azure and Amazon Web Services (AWS) back-up services.

Within these services backup plans define how databases are automatically backuped (e.g. frequency, time window, storage zone, storage region).

Backups are stored in a designated backup vault.

Schedule

• Daily: Differential Database backups – every day at 20:00 hour

• Weekly: Full Database backups - every Saturday at 2:00 hour

• Hourly: Transaction log backups

• Daily: every day scheduled at 05:00 hour

• Every 5 minutes: transaction log back-ups

The back-up schedule contains daily, weekly, monthly and hourly back-ups of different types (e.g. full, differential, transaction logs).

Point in time restore
supported

Yes (for 30 days)

Yes (for 7 days)

Point in time restore is supported.

Retention

• Daily: 180 days

Backups are automatically deleted using standard functionality within Azure.

• Daily: 180 days

Backups are automatically deleted using standard functionality within AWS

Backups are retained for at least 30 days (depending o the type of back-up).

Backups are automatically deleted using standard functionality within Microsoft Azure and AWS.

Recovery time objective (RTO)

8 hours

8 hours

8 hours

RTO comment

The actual time it will take to restore a back-up is not 8 hours (this is more like half an hour). We use an RTO of 8 hours because restoring a backup will most likely also mean ‘loss of data’ and is therefore seen as a last resort when other options are not able to resolve the situation within the service levels agreed to with clients. The 8 hours is based on an availability of 99% which means 7,3 hours downtime a month (rounded up to 8 hours).

Same as commented for Azure.

N.A.

Recovery point objective (RPO)

1 hour (the maximum loss of user data is work done in the last hour (since the last transaction log backup).

5 minutes

1 hour

Storage location

Amsterdam, The Netherlands, at a different Azure zone than the production environment (an Azure zone can be seen as a physical different location)

Frankfurt, Germany, at a different AWS Availability Zone (AZ) than the production environment (an AWS AZ can be seen as a physical different location)

Back-ups are stored in datacentres of Microsoft Azure (The Netherlands) and Amazon Web Services (Germany).
Storage is in different availability zones than the zones used for production environments. Availability zones can be seen as different physical locations.

Stored encrypted

Yes

Yes

Yes

Access

Limited to database administrators

Limited to AWS system administrators

Limited to system administrators.

Type of deletion

Hard deletion

Soft deletion (no deletion after certain number of days)

N.A.

Restore types supported

• System failover

  • Full database: yes

  • Client database: no

• User mistake

  • Object (e.g. tender): yes, through bin functionality

  • Document (e.g. pdf with tender specifications): yes, through Blob Storage functionality

• NOTE: Services to correct user mistakes are only supported in case of high impact cases/situations.

• System failover

  • Full database: yes

  • Client database: yes

• User mistake

  • Object (e.g. tender, contract): yes, through bin functionality

  • Document (e.g. pdf with tender specifications): yes, through AWS S3 versioning functionality NOTE: Services to correct user mistakes are only supported in case of high impact cases/situations.

• System failover (e.g. virus attack, hardware failure)

• User error (e.g. accidental deletion)

  • Objects (e.g. tender) via ‘bin functionality’.

  • Documents (e.g. tender specifications .pdf) via AWS and Azure specific functionality

NOTE: Services to correct user errors are only supported in case of high impact cases/situations.

Monitoring and control

See Generic.

Backups are monitored and alerted by AWS Simple Notification Service (SNS).

See Generic.

Back-up restore test are performed twice a year. The verification process includes the following items:

• Copying an encrypted backup

• Decrypting said backup

• Extracting said backup

• Restoring said backup

• Verifying data is not corrupt

Back-up related controls are part of our ISAE3000 control framework and part of the annual audit by KPMG.

Execution of back-up scripts is monitored on a daily basis. Backup failures trigger an incident by alerting the Security Officer.

Documents

Method

Taken care of by Azure through special service ‘Blob storage’. 99,99% availability through SLA with Azure.
SLA for Storage | Azure

Taken care of by AWS through special service ‘S3 buckets’. 99,99% availability through SLA with AWS.
https://aws.amazon.com/s3/sla/

Document back-ups are taken care of by special services within Microsoft Azure Blob storage and AWS S3 buckets. These services quarantee 99,99%, backed up by SLA’s.

Versioning enabled

??

Yes

Code

Method

Virtual Machines in Microsoft Azure are backed up through Azure Backup.

Manually created snapshots of the virtual machine instances.

Code back-ups are done via back-ups of virtual machine instances.

Schedule

• Daily at 3:00 AM

• Instant recovery snapshot allows for quick recovery of copies
  
  

Only when there is an update in the instance settings, a new image is created.

Planning to go for a half-yearly scheduled snapshot creation.

??

Retention

• Daily backup for 30 days

• Instant recovery snapshot(s) for 2 days

-

??