Not every business needs a WAF immediately, but there is no one-size-fits-all answer. The level of necessity depends on the type of data you handle, your application architecture, and the level of damage if the system experiences an incident. This article provides 5 specific questions to help you determine your position, rather than reading another list of "10 reasons to use a WAF" and still being unsure if you truly need one.

1. Why is the question "Should I use a WAF?" difficult to answer?

Because the correct answer is not "yes" or "no," but depends on the data processed, application architecture, and the severity of a potential incident. While saying "every business with a website should use a WAF" is theoretically correct, it doesn't help you decide whether to allocate budget for a WAF right now.

Three reasons why this question is harder to answer than it appears:

A WAF is not a binary (yes/no) investment but has various levels: free cloud WAF included with a CDN, managed service WAF, or dedicated WAF/WAAP for microservices architecture. "Do I need a WAF" is really "what type do I need, and at what level."
A WAF cannot replace HTTPS/SSL; many businesses have SSL and think that is safe enough. SSL only encrypts the transmission and cannot stop SQL injection or XSS at the application layer.
The opportunity cost of NOT using a WAF is difficult to quantify until an incident occurs; this is why most businesses delay the decision, even if it is not necessarily the right one.

The 5 questions below help you score your level of urgency, rather than relying on a feeling of "maybe I should have one."

2. Does your application handle user data?

This is a foundational question. The more personal, financial, or personally identifiable information (PII) that passes through the application, the greater the risk and legal liability if attacked.

High risk if your application has:

Payment information, card numbers, transaction history.
Personally identifiable information (ID card numbers, phone numbers, addresses) at scale.
Health, financial, or other sensitive information.

Lower risk if the application is only:

A corporate introductory website with no user accounts.
A landing page collecting simple contact forms with no sensitive data storage.
A successful SQL injection attack on a system containing sensitive data causes not only downtime but also involves data breach notification obligations, reputational damage, and in many cases, specific legal liability.

3. Do you have input forms, logins, or public APIs?

This question concerns your attack surface—the more points that receive user input, the more opportunities to exploit vulnerabilities.

Points to review:

Input forms: Search, registration, checkout, file upload each is a potential point for SQL injection, XSS, or file upload exploitation.
Login pages: A common target for brute force and credential stuffing (using leaked email/password lists to attempt mass logins).
Public APIs: If your application has APIs for mobile apps, integrated partners, or webhooks, this is a completely different attack surface compared to a traditional website. Basic WAFs primarily monitor HTTP/HTTPS request/response at the web level. If your architecture is API-first or microservices, consider WAAP (Web Application and API Protection) an extension capable of analyzing JSON/XML payloads and complex request flows that traditional WAFs do not handle well.

If your application displays almost entirely static content with no user input, the urgency for a WAF is significantly lower than for an application with logins, payments, and open APIs.

4. Have you ever been attacked or had abnormal logs?

This is the most practical question but also the most easily overlooked because most SMEs do not have anyone monitoring logs closely enough to know the answer.

Signs to look for:

Unusual spikes in requests to the same endpoint (signs of vulnerability scanning or brute force).
Server logs reporting constant 500 errors from the same IP range.
User accounts reporting logins from strange locations.
The website was previously slow or down without a specific technical cause.

If the answer is "I don't know" rather than "not yet," that itself is a signal. Lacking the ability to monitor logs means you cannot rule out the possibility of being silently attacked (e.g., bot scans running in the background without causing an obvious incident). In this case, implementing a WAF often brings an important secondary benefit: logging and visibility into attack traffic that you previously could not see at all.

5. Actual data: What is the level of web application attacks in Vietnam?

If the answer to section 4 is "I don't know," a few figures from the Q1/2026 report by Viettel Threat Intelligence can help visualize the scale of the problem, rather than just relying on the feeling that "my business is surely not a target."

DDoS attacks targeting the application layer and web infrastructure are rising sharply. In Q1/2026, the number of DDoS attacks increased 4 times compared to the same period last year, with peak intensities nearing 3.7 Tbps. The most targeted groups are businesses providing Hosting services, along with IT, digital entertainment, education, and public services.

Application-layer vulnerabilities remain the most exploited entry point. The report recorded 26 new vulnerabilities with high impact potential for Vietnamese businesses during the quarter, with over 53% rated High and Critical. Hackers are also actively exploiting old vulnerabilities with long-standing public exploits such as Apache Log4j, Confluence Data Center and Server, or React Server Components (CVE-2025-55182). These all allow remote code execution without authentication and reside at the web application layer—the exact type of attack a WAF is designed to block at the request layer before reaching business code.

Data leaks via web applications continue to escalate. 165 data leakage incidents were recorded in the quarter, with over 473.7 million records leaked, a 2.4-fold increase year-on-year. Retail/E-commerce and Securities/Investment were among the most heavily affected sectors. For Finance/Banking, despite fewer incidents (7 cases), the damage was greatest, with over 188.9 million records compromised in this group alone.

These three data sets show a commonality: DDoS, vulnerability exploitation, and data leakage mostly go through the same gateway the web application layer. This is why a WAF is often mentioned as a must-have defense layer, not a "just in case" investment.

Data source: Vietnam Information Security Threat Situation Report Q1/2026, Viettel Threat Intelligence

6. Do you have to comply with personal data protection laws, payment card security standards, or customer security requirements?

This is the question that can turn "should consider" into "must have" immediately.

PDPL (Personal Data Protection Law 91/2025/QH15): Does not explicitly require a WAF by name, but requires technical protection measures commensurate with risks when processing personal data. A WAF is a common technical measure cited when proving "appropriate protection measures have been applied" in a DPIA profile.

PCI DSS: If a business processes payment card information directly, PCI DSS specifically requires web application protection at layer 6 and layer 11; a WAF is one of the accepted options to meet this requirement.

B2B customer requirements: Many large customers, especially in finance/banking, require suppliers/partners to demonstrate a web application protection layer as a contractual condition or security audit requirement before signing.

If you fall into any of the above, a WAF is no longer a question of "do I need it" but rather "which type to deploy and when."

7. If the app is down for 2 hours, what is the damage?

This question helps convert security risk into specific business figures, which is easier to justify in a budget decision than "might be attacked."

How to estimate quickly:

Direct revenue loss: Average revenue per hour (for ecommerce or transaction apps) x 2 hours.
Incident handling costs: Technical team man-hours, emergency outsourcing costs if needed.
Reputational costs: Hard to quantify but real: customer attrition, negative reviews, impact on deals currently being negotiated.
Legal costs if the incident involves data leakage: breach notification obligations, potential administrative penalties under personal data protection regulations.

If the figure in step 1 is far higher than the monthly cost of deploying and operating a WAF, the investment decision is almost obvious. Conversely, if 2 hours of downtime has almost no effect on revenue or customers, the security budget may prioritize other things first.

8. Self-assessment results: Which group are you in?

Count the number of "high risk" answers in the 5 questions above and compare:

Group 1: Need a WAF immediately (4-5 "yes" answers) Application handles sensitive data, has logins/public APIs, is subject to specific compliance constraints, and potential downtime damage is significant. This is no longer a "should I" decision, but "which type and when," and should be prioritized this quarter.

Group 2: Should have in the next 3-6 months (2-3 "yes" answers) Has some risk factors but is not immediately urgent (e.g., has logins but no specific compliance constraints, or has sensitive data but on a small scale). Should be put on the nearest security roadmap, while starting by setting up log monitoring to have better data for decision-making.

Group 3: Not an immediate priority, but needs monitoring (0-1 "yes" answer) Application has a small attack surface, no specific legal constraints, and low downtime damage. Prioritize basic measures first (HTTPS, patch updates, backups) and reassess when there are changes in scale or the type of data processed.

Important note: This self-assessment result is only a starting point and does not replace a formal security risk assessment, especially if you fall into Group 1.

9. If you need a WAF, what are the practical next steps?

For Groups 1 and 2, the actual implementation steps should follow this order:

Determine the appropriate deployment model: Cloud WAF (fast, low cost, no specialized team required) is suitable for the majority of SMEs; on-premise/hardware WAF is only necessary when there is a requirement for extremely low latency or constraints that data must not leave the internal infrastructure.
Check if data needs SSL decryption for analysis: With cloud WAF, traffic usually needs TLS decryption at the provider side to analyze payloads. If the application processes sensitive personal data of Vietnamese users, it is necessary to clarify where the data is processed and by whom this is a point to cross-reference with the DPIA profile if the business already has one.
Do not deploy and leave it at default: A WAF needs to be fine-tuned with rules based on application characteristics (forms, APIs, real user behavior) in the first few weeks; otherwise, you will only be running the provider's default configuration, which is prone to blocking real users (false positives) and missing sophisticated attacks.
Remember that a WAF is not a silver bullet: A WAF cannot detect business logic flaws (e.g., vulnerabilities allowing privilege escalation through parameter editing) and is difficult to defend against zero-day attacks. A WAF should be one layer in a multi-layered security strategy, not the only solution.

With infrastructure running on VKS or vServer from GreenNode, integrating a CNCF-compliant WAF/WAAP does not require architectural changes. GreenNode supports infrastructure and technical documentation for your team to deploy a protection layer suitable for the data processed in Vietnam.

Is a WAF Truly Necessary for Your Business? 5 Self-Assessment Questions to Determine Priority and Mitigate Web Application Security Risks