What Qatari buyers ask their suppliers
Banks, government bodies, health organisations and large retailers in Qatar commonly send suppliers a security questionnaire before they sign. The questions are often tied to the national information assurance standards from the national cybersecurity authority, to sector rules, and to the buyer's own policy. Which of those apply to your product is for your buyer and your counsel to say. What you can control is having the evidence ready.
| Buyer asks | Evidence that answers it | Where we help |
|---|---|---|
| Who can see and change what? | A roles and permissions matrix, multi-factor authentication, session and password rules | Threat modelling and the design of access control |
| Where is our data? | A data map, the hosting region, and where backups and logs go | Architecture choices in a discovery sprint |
| Was it tested? | A penetration test report with retest results | Penetration testing |
| Is the code reviewed? | Review notes and a fix list tied to the code | Secure code review |
| What if something goes wrong? | Logging, alerts and a written incident plan | Incident readiness, below |
| What does it depend on? | An inventory of libraries and services, with scanning | Dependency scanning in the release pipeline |
Where our security work fits
We treat security as a sequence, not a final gate. Each step produces something your team can read.
Threat review at the start
Before the design is final we map the core flows, such as sign-in, payment, data export and admin actions, and ask what could go wrong at each step: stolen accounts, tampered requests, exposed files, abused features. A change made at this stage costs a conversation, not a rebuild. Threat modelling for small teams explains the method, and the glossary defines threat modelling.
Secure code review during the build
We read the code that carries the risk: authentication, authorisation, input handling, file upload, secrets and payment callbacks. We check it against the OWASP Top 10 categories, including SQL injection and cross-site scripting. Reviews run alongside delivery, so findings are fixed while the code is fresh.
Penetration testing before launch
A penetration test attacks the running product, with written permission and an agreed scope, to find what a reviewer reading code cannot: logic flaws, misconfigured hosting, weak sessions. It differs from an automated scan, as penetration test vs vulnerability scan explains. Some buyers, especially in regulated sectors and government, require testing by a supplier on an approved list. We cannot tell you whether that applies to you, so ask your buyer or counsel before you commission a test.
A prioritised fix list and a retest
Every finding gets a severity, the evidence, the steps to reproduce it and a recommended fix. After the fixes we retest, so the report shows what was found and what was closed.
Hosting and data location questions
Where data lives is a legal question and a technical one. Qatar's personal data law and the Qatar Financial Centre's own data protection rules are the starting points for your counsel, and sector rules or your clients' contracts may add conditions. Settle these questions before you pick a region.
- Must personal data stay in Qatar, or may it be processed in another country on conditions?
- Which regions of AWS, Azure or Google Cloud are available near your users, and do they offer the services you need?
- What leaves the primary region without anyone noticing: backups, logs, error trackers, analytics, email providers, support tools?
- Who can administer production, from where, and with which controls?
The technical answer is a data map that lists every place data goes, encryption in transit and at rest with keys you control, separate environments, no production data in testing, and logs that hold no personal data. We build that map early because it decides the architecture. The secure app development guide covers the controls in more detail.
Reports your compliance team can use
A report is useful only if someone who missed the meeting can act on it. Ours has an executive summary, the scope and method, then each finding with its severity, evidence, reproduction steps, recommended fix and retest status. We write in English and can provide the summary and the finding titles in Arabic where your management or compliance staff prefer it. Code, commands and tool output stay in English, because that is the language developers and security tools use.
If your buyer has a control list, tell us and we map findings to it. Mapping is not certification. It helps your team show how the evidence relates to the controls they report against.
Incident readiness
A secure product can still have an incident, and the first hour shapes how it goes. We help you prepare the parts that live in the product and the parts that live in the team.
- Security events are logged: sign-ins, permission changes, exports, failed payments and admin actions. Logs avoid personal data.
- Alerts reach a person who can act, during the Sunday to Thursday week and out of hours.
- Backups are restored in a test, not only taken.
- A one-page plan says who decides, who speaks to users and who speaks to counsel.
- A published route lets researchers report problems, such as the vulnerability disclosure policy we keep for our own site.
Ask counsel who must be told, and when, if personal data is exposed, because the answer depends on the law and on your contracts. Then write it into the plan so nobody searches for it during an incident.
Awareness of national standards
Qatar's national information assurance standards and the rules of sector regulators, such as the central bank for financial institutions, are the reference many buyers use. We design with awareness of that landscape and organise evidence so it is easy to relate to a control list. We do not offer certification, we do not audit you against a standard, and we cannot promise that a product will pass a client's or a regulator's assessment.
This page is awareness, not legal advice. Standards, regulators and legal duties change. Confirm which apply to your product with qualified local counsel and with your buyer.
For the wider picture see software development and security for Qatar, and for the general service see cybersecurity.