Naturally you too are responsible for the security and privacy of your customer’s data. Simple everyday examples of where this can already go wrong, is the using of simple passwords, the sharing of user accounts and users ‘forgetting’ to log out. i-Reserve helps you prevent this by offering the option to require passwords to have specific detail such as a minimum number of characters, numbers, capitals and special characters. Another option built into i-Reserve, is forcing a mandatory change of the users password every x number of days.

Of course it is good practice for you as an organisation to ensure that a user account is created for everyone (this does not entail any extra costs) and that the rights based on user groups are correctly setup. There is also the option to configure the length of a logged-in session, thereby overcoming the issue where users ‘forget’ to logout.

In short, there are sufficient possibilities that allow you to take responsibility and to prevent misuse of (personal) data. In addition to that, below you can find more information on how the security and privacy of (personal) data is ensured in i-Reserve.

Secured connection

As a service i-Reserve is delivered with a SSL certificate (privacy by default). SSL (or actually TLS) can be recognised by https:// at the front of the url. This is a technique in which the connection between the visitor to a website, and the server where the website is hosted, is secured with very strong encryption. With a SSL connection we ensure that the information sent to and from the booking dialog cannot be ‘read’ or ‘modified’ by third parties.

Encryption of information

Besides encrypting data traffic on the internet via SSL (also called data in transit), i-Reserve offers the possibility to also apply encryption to physical data (also called data at rest).

Passwords are stored encrypted in i-Reserve. Also, when a password is forgotten we do not send a new password but rather a link indicating how to reset your password yourself.


When setting up a firewall we allow public IP addresses to connect only to the ports that are needed. For ports and functions that are critical from a security standpoint, we use a whitelist. Only IP addresses that are on this whitelist have access to those items.

Web Application Firewall (WAF)

A Web Application Firewall is an application that looks at and monitors inbound and outbound traffic. All traffic that is different or that goes against the rules of the firewall is blocked. In the case of serious ‘violations’ such as an attempted repeated MySQL injection, the offending IP address is put directly on the blacklist so that the sender can no longer make a connection.


It is possible to completely shield an i-Reserve environment from the outside world. This can be achieved by using IP-whitelisting. This completely blocks the domain, allowing it to be accessed only from specific IP addresses. This is used, for example, by customers who want to use i-Reserve as an internal application.

Prepared statements

Computer applications can be vulnerable to SQL-injection. Applications that store information in a database often use SQL to communicate with the database. SQL-injection can occur if user input is processed in an insufficiently controlled way in an SQL-statement.

Within i-Reserve we make use of prepared statements. This is a mechanism which ensures that unwanted code cannot be processed in the SQL queries that are executed by the application.

Slowdown mechanism

Brute force attacks occur when malicious users with a list of passwords and user names attempt to automatically login. The automatic process continues until a correct combination is found.

To suppress brute force attacks we use a slowdown mechanism. The first time there is an incorrect username/password combination entered, there needs to be two seconds delay before attempting a new combination. The second incorrect attempt prompts a four second delay.. the third time, sixteen seconds.. This is a way to disable the use of brute force attacks.

Lockdown mechanism

Should an intruder nevertheless still gain access, any attempt to give himself more rights will be made impossible by the system and he will be locked out.

Hosting and storing of data

All data is stored in the Netherlands. The i-Reserve application and the associated database run on a dedicated server. This means that the server is configured for i-Reserve and is only used by customers of Teqa Webworks. The data can only be accessed by the i-Reserve application and no other sources have permission to connect to the database.


i-Reserve does not use shared databases. Each customer has its own database with unique login credentials. This minimises risk, should any data leak occur.

Daily backups

To ensure that data is not simply lost, we run daily automated backups. Both the database and the file system are backed up every day and the backups are stored on a separate server for 30 days.

Daily scans

We perform a daily automated scan with McAfee Secure which tests the security of our servers. We also do a daily scan for malware and viruses and have proactive control over this.

Segregation of duties

Segregation of duties (or function splitting) is the concept that certain responsibilities are spread over more than one person. For example, programmers and developers do not have access to customer databases. Only those people who need access to production systems and databases for their work, have access to them.

Automatically anonymize personal data

In order to comply with legislation relating to the processing of personal data, i-Reserve offers the ability to automatically anonymize relevant personal data. Once your stored data becomes no longer necessary, it can be anonymised. This also facilitates legislation regarding a person’s ‘right to be forgotten’.

This functionality is not enabled by default and needs to be set by the administrator (privacy by design).

Open Web Application Security Project

i-Reserve complies with the widely used OWASP top 10. The most recent topics in the OWASP top 10 are taken into account during the development of the application. The application is checked periodically and regularly – through various test phases – to ensure that it remains compliant to these requirements.