Web Application Security: 10 Questions to Ask Your Developer Before You Sign

You are ordering an app and you are not a programmer. So how do you check whether a contractor takes web application security seriously and whether GDPR compliance in your app will actually be handled? Good news: you do not need to read code. Before you sign the contract, ask these 10 specific questions and listen carefully to the answers. For each one we show what a good and a bad answer sounds like.

Why ask about security before signing?

Because after launch it is too late and too expensive. Fixing the foundations of a live application costs many times more than building them right from day one. The questions are the same whether you hire an agency or a freelancer - if you are still choosing, read our post software house or freelancer. Security basics are not a premium add-on either - they come as standard whether the project costs PLN 10,000 or PLN 100,000. You are not running a technology exam - you are watching how the contractor reacts. Specifics and procedures are a good sign. Vague answers and impatience are not.

Web application security: data, backups and access (questions 1-4)

1. How do you back up data, and when did you last test a restore?

Good answer: automatic nightly backups stored away from the application server, restores tested regularly. Bad: "the hosting provider handles something like that". A backup nobody has ever restored is a hope, not a safeguard.

2. Does everything run over HTTPS, and how do you encrypt data?

Good: HTTPS everywhere from day one, passwords stored only as hashes, sensitive data encrypted in the database. Bad: "we'll add the certificate before launch". A sign that security is an add-on, not a foundation.

3. Who on your side can see our data, and how do you split permissions?

Good: a named list of people, each with their own account, permissions assigned by role. Bad: one shared admin password "because it's easier". You will never establish who did what.

4. How do you update the libraries the app is built on?

A typical web app relies on dozens of ready-made components, and vulnerabilities in them surface all the time. Good: updates are part of post-launch maintenance, with a clear plan. Bad: "once we hand over the project, that is your problem".

GDPR in your app: personal data and the end of cooperation (questions 5-6)

5. How will you handle GDPR, and will you sign a data processing agreement?

If the app processes customer or employee data, GDPR applies to it directly. Good: a data processing agreement is standard, test data is anonymised, servers sit in the EU. Bad: "GDPR is a job for your lawyer, not for us".

6. What happens to your access once the cooperation ends?

Good: a written offboarding procedure: access handed over, accounts disabled, passwords changed, confirmation in writing. Bad: surprise that you even ask. Former contractors with live access are one of the most common security holes in small companies.

Code, logs, testing and a failure plan (questions 7-10)

7. Who owns the code, and on what terms do I get it?

This comes down to the contract, and both models can be fair: a copyright transfer or a license to use the code - they differ in scope, price and what you may later change on your own. Good: the vendor says plainly which model they propose and what it covers, and the terms and timing of handing over the code or repository access are written into the contract. Bad: "the code is with us, don't worry" - with nothing in writing. It is not about access from day one; it is about knowing what you will get, when, and on what terms - so you are never left hostage to a single vendor.

8. What events does the application log?

Good: logins, data changes and errors are recorded, with a defined retention period. Bad: no logs at all. After an incident you will not know what happened - or whether you must report a data breach.

9. How do you test the app before deployment?

Good: a separate test environment, automated tests of the key features, and code review by a second engineer - including code written with AI. Bad: "we click around, and if it works, we ship".

10. What happens if the app goes down on Friday at 10 pm?

Good: monitoring that raises the alarm on its own, a response time written into the contract and a clear contact path. Bad: "nothing has ever gone down on us". One day it will - the question is whether anyone knows what to do.

Summary: how to read the contractor's answers

You do not need to follow every technical detail. Watch for three signals:

• Specifics over generalities - "nightly backups, stored off-server" instead of "we've got it covered".
• Procedures over improvisation - failures and offboarding have a described process, not a promise.
• Willingness to put it in the contract - a good verbal answer nobody wants to write into the contract is worth little.

Want an engineer to review a contractor's offer or your existing app? Book a technical consultation. And if you are still planning the project, use our quote tool: the calculator gives you a ballpark range on the spot, a real person replies within 24 hours, and you get a binding quote after a short call - with answers to all 10 questions.