Your Sumrite questions, answered.

A VAPT report is a formal document issued after a completed vulnerability assessment and penetration test. It confirms that your application has been tested by a qualified security expert following recognised standards. It is commonly used as evidence for SOC 2 Type 2 audits, ISO 27001 vendor assessments, PCI DSS requirements, enterprise client onboarding questionnaires, and regulatory reviews such as DIFC and ADGM.

Sumrite delivers a complete VAPT report within 48 hours of engagement start for standard web application and API tests. Complex applications, cloud infrastructure reviews, or red team operations may take 3 to 5 days. The industry average is 2 to 4 weeks. We are significantly faster without cutting corners because there is no sales or project management layer between the expert and the report.

Sumrite reports are mapped to 23 frameworks across five regions: SOC 2, SOC 1, ISO 27001, PCI DSS, HIPAA and NIST CSF worldwide; GDPR, DORA, NIS2 and the Cyber Resilience Act in Europe; NCA ECC, CCC and DCC, SAMA, the Saudi, UAE, Omani, Qatari, Bahraini and Egyptian data protection laws, and DIFC and ADGM in the Middle East; the DPDP Act, SEBI CSCRF and RBI in India; and APRA CPS 230 and 234, the Australian Privacy Act and ST4S in Asia-Pacific. Enterprise onboarding questionnaires and government tender requirements are covered too.

We use automation for what it does well: routine checks such as missing security headers, exposed server details and known-vulnerable components. That layer is free at scan.sumrite.com. Everything in a Sumrite report beyond it is found and verified by a security expert following OWASP Testing Guide v4.2, NIST SP 800-115 and PTES. We never hand over raw scanner output as a penetration test, because scanners miss business logic flaws, access control issues and chained vulnerabilities.

Yes. Run it with no card and no sales call. In about five minutes it shows what an attacker sees first, such as a missing Content-Security-Policy, HSTS not enforced, a disclosed Server header and missing clickjacking protection, so you can see where you stand before you talk to us. For the flaws a scanner cannot see, our experts take over.

Sumrite provides fixed-price quotes scoped to your application. Contact us at sumrite.com/contact and receive a quote. There is no commitment required to receive a quote and we sign an NDA before any technical discussion.

A vulnerability scan uses automated tools to identify known issues by pattern matching. A VAPT adds expert testing: chaining vulnerabilities, abusing business logic and verifying every finding by hand. The scan finds the checklist items; the expert finds the flaws that actually matter to your business and your clients.

Yes. Sumrite provides VAPT reports that UAE teams use as technical evidence in DIFC, ADGM and CBUAE reviews. We serve clients across the Gulf region including UAE, Saudi Arabia, Qatar, Bahrain, and Kuwait. Reports are delivered remotely within 48 hours.

A Sumrite VAPT report includes an executive summary for non-technical stakeholders, a detailed technical section with every finding, CVSS severity scores, step-by-step proof of concept for each vulnerability, developer-ready fix guidance in plain language, a remediation timeline, and a signed security report. Re-testing after fixes is included at no extra cost.

Sumrite tests web applications, REST and GraphQL APIs, iOS and Android mobile apps, cloud infrastructure on AWS, GCP, and Azure, internal networks, source code, thick client applications, phishing simulations, and performs red team operations simulating real attackers.

Yes. Most of our clients are SaaS companies, fintech startups, and B2B software teams between seed and Series B. Security testing is often triggered by an enterprise client requiring a VAPT report before onboarding, a compliance audit, or a product launch. We are faster and more pragmatic than traditional security firms.

Sumrite is based at E-211 FFC, Okhla Phase 3, New Delhi, Delhi 110020, India. Testing is delivered remotely, so we work with clients across India, the Gulf, Europe, Australia and North America.

Yes. Sumrite runs objective-based red team operations that combine phishing, external compromise, identity and cloud attack paths and lateral movement, mapped to MITRE ATT&CK, to test whether your team detects and stops a real attacker. Most organisations start with regular VAPT and add red teaming once that is in place.

Neither standard uses the words penetration test, but auditors routinely expect one. SOC 2 lists penetration testing as a point of focus under CC4.1, and ISO 27001 Annex A 8.8 requires technical vulnerabilities to be found and treated. An annual independent VAPT with a retest is the usual evidence.

The free scan finds scanner-level issues such as a missing Content-Security-Policy, HSTS not enforced, a disclosed Server header and weak clickjacking protection. It cannot log in as two customers and test whether one can read the other's data, understand your business rules, or chain small issues into a real attack. That is the work Sumrite's experts do in a paid engagement.

A written scope (URLs, API specifications, mobile builds or cloud accounts), test accounts for each role, ideally two tenants, a stable environment that mirrors production, and one named contact who can answer questions quickly. An NDA is signed before any technical discussion.

Yes. An NDA is signed before technical discussion and before any credentials or system details are shared.

Yes. Fixed findings are retested and the report is updated to show what is now closed, so you can show customers and auditors that issues were resolved.

A penetration test finds and proves weaknesses in a defined scope. A red team operation pursues a goal, such as reaching sensitive data, while testing whether your people and tools detect and respond.

Reports are written with scope, methodology, verified findings, evidence and a retest, which is what auditors and vendor security reviewers look for. Findings can be mapped to the framework you name in scope, across 23 frameworks worldwide.

Sumrite serves clients worldwide, with dedicated guidance for India, the UAE, Saudi Arabia and the wider Gulf, Australia, Germany, France and the rest of Europe, the UK and North America.

Yes. Share the questionnaire or contract clause when you request a quote and we will scope the test and organise the report so reviewers can map findings to their controls.

At least once a year for internet-facing and critical systems, after major releases, new payment flows or cloud migrations, and whenever a customer, auditor or regulator requires it. Run a vulnerability scan more often, monthly or continuously.

Either, as agreed in writing. Staging that mirrors production is quicker and safer for deep testing; production testing is scoped carefully with safe methods and agreed windows.

They are used only for the agreed engagement, shared under NDA, and removed when the engagement ends. Test accounts and temporary access should be revoked by your team once testing and retesting are done.

Sumrite's security experts. Tools speed up routine checks, but every finding in the report is reproduced and confirmed by an expert, with evidence and fix guidance.

Yes. For frameworks that end in a third-party report, such as SOC 2, SOC 1, ISO 27001, PCI DSS, NCA controls or a CERT-In audit, we run the full engagement for you and route the formal step through our local partner firms, so you deal with one team and get all your work done.

Yes. Everything on this hub is free to read. Ask us if you want a walkthrough tailored to your stack.

Sumrite’s penetration testers and security consultants. Pages are reviewed regularly and dated.

Start with the pre-launch checklist and the framework your first customers ask about, then book an expert-led penetration test.

Start with what your customers or auditors are asking about. For most SaaS companies that is a web application test, usually combined with the API behind it. Add mobile, cloud or network testing when those are part of what you sell or where your data lives.

For a scoped web application or API, the report is delivered within 48 hours of testing starting. Network, cloud, red team and larger multi-service engagements take longer; the timeline is confirmed in the fixed-price quote before work begins.

Yes, on standard engagements. Once your team has fixed the findings, they are tested again and the report records which issues are now closed.

An information security auditing organisation that CERT-In has evaluated and placed on its published panel. CERT-In maintains the list; the report is issued in that firm’s name.

No. CERT-In does not certify organisations through empanelment. The empanelled auditor performs the audit and issues the report and, where requested, an audit certificate or compliance letter.

Yes. Sumrite runs scoping, testing, remediation support and the retest, and routes the formal audit through its CERT-In empanelled partner, so you deal with one team from start to finish.

CERT-In’s audit guidelines call for audits at least once a year and after major changes. Your regulator, sector rules or contract may set a different frequency; follow whichever is stricter.

A test carried out by an NCSC approved CHECK company and CHECK qualified staff, used for UK public sector and CNI systems.

A tester approved under CHECK, CREST or Tigerscheme.

Yes, through its UK partner companies that hold the accreditation, with Sumrite running the engagement end to end.

Sumrite delivers CREST accredited testing through a CREST member company in its partner network. The formal testing and report come from that accredited company, while Sumrite runs the engagement end to end.

Companies are accredited by CREST; individual testers are certified, for example as CREST Registered or Certified Testers. Accredited companies must employ certified staff.

No. They require an independent, competent test. CREST matters when a regulator, buyer or tender names it.

Yes. Under the Cybersecurity Act, providers of penetration testing services in Singapore must be licensed by the CSA.

Yes, through its CSA licensed partner in Singapore, with Sumrite running the engagement end to end.

Yes. Findings can be mapped to the MAS Technology Risk Management guidelines.

A DESC programme that certifies cybersecurity service providers, including penetration testing providers, to serve Dubai government entities.

Yes. Sumrite runs the engagement end to end and routes the certified provider step through its DESC certified partner in the UAE.

Usually only when they work for Dubai government entities or a contract names it. Otherwise an independent expert-led test, or CREST where asked, is the norm.

Testing by a firm that a national authority or industry body has empanelled, accredited, licensed or registered, such as CERT-In, CREST, the NCA, DESC, NCSC CHECK, ANSSI PASSI, the BSI, ASD IRAP, the CSA or the PCI SSC.

Sumrite delivers accredited testing through partner firms that hold each scheme. Sumrite runs the engagement end to end, and the partner issues the formal report or attestation where the scheme requires it.

The one named in your regulation, tender or contract. Send us the wording and we will confirm it before quoting.

Often yes. One round of testing can be mapped to several frameworks, with separate formal reports where each scheme requires its own.

An assessment by an ASD-endorsed IRAP assessor of how well a system implements the controls in the Information Security Manual.

No. IRAP is a controls assessment; penetration testing is often part of the evidence it reviews.

Yes, through Australian partners that hold them, with Sumrite running the engagement end to end.

The NCA licenses cybersecurity service providers, including penetration testing. Entities covered by NCA controls and contracts that name the requirement should use a licensed provider.

Yes. Sumrite runs the engagement end to end and routes the licensed provider step through its NCA licensed partner in Saudi Arabia.

No. PCI DSS requires a qualified, organisationally independent tester for 11.4. ASV scans (11.3.2) must be run by a listed ASV, and a Report on Compliance by a QSA.

At least once every three months and after significant changes, with a passing result each quarter.

Yes, through PCI SSC listed partners, with Sumrite running the penetration testing and coordinating the whole programme.

Threat-led penetration testing under the Digital Operational Resilience Act: an intelligence-led red team test of live production systems behind critical functions, required at least every three years for designated financial entities.

A security audit by a provider qualified by ANSSI, France’s national cybersecurity agency, under the PASSI scheme.

Yes, through European partners that hold those qualifications, with Sumrite running the engagement end to end.

No. The scan analyses the build. A penetration test also tests the running app on a device and the APIs behind it, by hand.

The build is used to produce your report. See the privacy policy for how scan data is handled.

Yes. Upload the .ipa build in the same box.

Start with p=none and reporting to find all your legitimate senders, then move to p=quarantine and p=reject.

Yes. DMARC relies on SPF and DKIM results; without DMARC, receivers decide on their own what to do with failures.

Yes. A CNAME pointing at a deleted cloud resource can let someone else claim it and serve content on your subdomain.

Yes. There is no card and no sales call. The full website report is also sent to your work email.

Yes. They read public responses, DNS and certificates and check which ports answer. No exploit payloads are sent.

Broken access control, business logic flaws and chained attacks. Those need an expert-led penetration test.

Response headers that instruct the browser to enable protections, such as blocking framing, enforcing HTTPS or restricting which scripts may run.

Content-Security-Policy and Strict-Transport-Security, followed by clickjacking protection, X-Content-Type-Options and correct cookie flags.

No. Headers are scanner-level findings. Access control, business logic and chained attacks need an expert-led penetration test.

TLS is the modern successor to SSL. People still say “SSL certificate”, but every current secure connection uses TLS.

TLS 1.2 and TLS 1.3 only. TLS 1.0 and 1.1 are deprecated.

No. It makes normal connections, the way a browser does.

It searches certificate transparency logs, where every publicly trusted certificate is recorded, and queries DNS for the names it finds.

Certificate transparency logs are public. Sumrite’s scanner only runs deeper checks on domains you confirm you own.

Remove what you do not need, put internal tools behind a VPN, and include the rest in your penetration test scope.

There is no single law that makes VAPT mandatory for every company. It is required for entities regulated by SEBI, the RBI and IRDAI, for many government systems through CERT-In audits, and in practice by enterprise customers and auditors. The DPDP Act also requires reasonable security safeguards, which testing helps you prove.

Only when a regulator, government body or contract asks for one. For SOC 2, ISO 27001 or a customer review, an independent expert-led VAPT report is enough. When an empanelled audit is required, Sumrite runs the engagement and routes the formal audit through its CERT-In empanelled partner.

For a scoped web application or API, Sumrite delivers the report within 48 hours of testing starting. Larger scopes, such as several applications or an internal network, take longer; the timeline is confirmed in the fixed-scope quote.

Yes. Sumrite is based in Okhla, New Delhi, and can test internal networks on site in Delhi NCR. Most application, API and cloud testing is done remotely.

Sumrite is at E-211 FFC, Okhla Phase 3, New Delhi, Delhi 110020.

Yes. Sumrite works with companies across Delhi NCR, including Noida, Gurugram, Faridabad and Ghaziabad, on site for internal network testing and remotely for applications, APIs and cloud.

Yes. Sumrite runs the engagement and routes the formal audit through its CERT-In empanelled partner, so you deal with one team in Delhi from scoping to the final report.

Once the scope is agreed and the NDA and testing authorisation are signed. For a scoped web application or API, the report is delivered within 48 hours of testing starting.

Where a regulator or contract names one, such as SEBI’s cyber audit, yes. Sumrite runs the engagement and routes the formal audit through its CERT-In empanelled partner.

At least yearly in most cases, with frequency for some SEBI entities set by category. Plan the test, fixes and retest before the submission date.

The customer web app, mobile apps and the APIs behind them, with authenticated testing across roles, payment and transaction logic, and third-party integrations.

At least once a year and after significant changes; many regulators and partner banks expect that cadence. Fast-shipping teams use continuous testing.

Yes. Sumrite tests connected devices, firmware and their apps and cloud in-house.

A recent date, a clear scope that matches the product they are buying, verified findings with severity, and proof that critical issues were retested and closed.

Because two applications with the same number of pages can need very different effort. A fixed quote for your scope is more accurate than a price list, and it does not change once testing starts.

It depends on scope, roles, depth and environment. The VAPT cost guide lists the factors and published market figures for comparison.

No. A retest of fixed findings is included on standard engagements.

Sumrite quotes in the currency that suits the contracting company, including Indian rupees, Saudi riyals, UAE dirhams and US dollars.

For a scoped web application, Sumrite delivers the report within 48 hours of testing starting. Larger applications with many roles or integrations take longer; the timeline is confirmed in the quote before any work begins.

No. A scanner matches known patterns and produces a list of possible issues. VAPT is expert-led: a tester confirms what is exploitable, chains weaknesses together and tests business logic that scanners cannot understand. Sumrite does not issue scanner output as a penetration test.

Either. Staging is preferred when it mirrors production closely. If production is the only option, test windows, rate limits and safety contacts are agreed in writing first.

Yes. AI assistants, RAG search and agents are tested as part of the application, with prompt injection, data leakage and tool abuse mapped to the OWASP Top 10 for LLM Applications. See <a href="/services/llm-ai-penetration-testing">LLM and AI application penetration testing</a>.

No. Every finding is reproduced and verified by a tester. Speed comes from preparing the scope in advance and testing in parallel, not from replacing manual testing.

When testing starts, after the scope, NDA, test accounts and authorisation are in place.

Yes. Fixed findings are retested and the report is updated at no extra cost on standard engagements.

Larger scopes take longer, but they can be split so the most important application is reported first. The timeline is confirmed in the quote.

A security test of a product feature built on a large language model. It checks what an attacker can make the feature do, such as leaking data, calling tools without approval or producing output that the application executes, and tests the APIs and cloud around it.

No. You cannot test the provider’s platform and do not need to. Sumrite tests how your application uses the model: its prompts, retrieval, tools, permissions and output handling.

The conventional application is still tested, but the model adds new inputs (any text it reads), non-deterministic results and actions it can take. Findings therefore include success rates and exact prompts.

AI red teaming usually focuses on model behaviour and harmful output. An LLM penetration test focuses on security impact in your product: data exposure, unauthorised actions and injection. Sumrite can combine both, and larger programmes can add red team operations.

Yes. Fixed findings are retested against the same attacks and the report is updated.

A base URL for a test environment, documentation if it exists (OpenAPI, Postman or GraphQL schema), and at least two accounts per role so cross-user access can be tested. Without documentation we map the API from the app's traffic.

Yes. GraphQL testing adds introspection, query depth and batching abuse, and field-level authorisation on top of the usual authentication and access checks.

Testing is done against agreed accounts and data, preferably in staging. Destructive actions are only performed on records we create, and the rules are agreed in writing first.

An IPA or APK build, or TestFlight and internal-track access, plus test accounts. A build without heavy obfuscation speeds up the work; release-build checks can be added if needed.

They can be tested together or separately. Where both apps share a backend, the API is tested once and the platform-specific checks are done on each app.

No. Store review checks policy and obvious malware. It does not test your access control, data storage or backend APIs, which is where most real mobile breaches start.

External testing looks at what anyone on the internet can reach. Internal testing assumes an attacker already has a foothold, such as a phished laptop, and measures how far they can move. Most organisations need both.

Yes. Internal tests are usually run through a small agreed access point, such as a VPN account or a test virtual machine placed on the network, so no one needs to be on site.

Testing is scoped to avoid disruption: no denial-of-service, agreed test windows, and a named contact on your side who can pause work at any time.

Read-only access, such as an audit role in AWS, a Reader role in Azure or a Viewer role in Google Cloud. No write access is needed for the configuration review; any validation beyond that is agreed separately.

Yes, when they are in scope. Cluster configuration, workload permissions, network policies and image hygiene are reviewed alongside the cloud account.

It overlaps. The assessment reviews configuration across the account; validation then shows which issues are exploitable. Applications hosted in the cloud are tested separately as web or API engagements.

Common web and mobile stacks, including JavaScript and TypeScript, Python, Java, C#, PHP, Go, Kotlin and Swift. Confirm your stack when you request a quote.

They find different things. A penetration test shows what an attacker can exploit from outside; a code review finds flaws in logic and design that may never be reachable in testing. Critical applications benefit from both.

Access is read-only and covered by an NDA signed before anything is shared. Code is reviewed in the agreed environment and access is removed when the engagement closes.

.NET (WinForms and WPF), Java, Electron and native Windows and macOS applications, together with the backend services they connect to.

The installer or build, test accounts, and access to a test backend. A short walkthrough of the main workflows helps the tester focus on what matters.

The client often holds secrets, cached data and logic of its own. Attackers with access to one laptop can extract those, or use the client to send requests the server was never designed to receive.

Usually not, so the results reflect real behaviour. Leadership and named contacts approve the campaign in writing and can stop it at any time.

No. The landing page records that a submission happened, not the credential itself, and no captured data is reused.

Many organisations run them several times a year so trends can be measured. The right frequency depends on your risk and any framework you report against.

A penetration test looks for as many weaknesses as possible in a defined scope. A red team pursues a specific objective, as quietly as a real attacker would, to test detection and response across people, process and technology.

A small group of named stakeholders approves it and acts as the safety contacts. Defenders are usually not told the timing, so their response is realistic.

It is most useful once regular penetration testing is in place and there is a security team or provider to detect and respond. Earlier on, penetration testing gives more value for the budget.

Usually two or three production-grade units, the firmware image if you have it, the companion app and test accounts, and any hardware or protocol documentation you can share. We can work without documentation, as an attacker would.

Some tests involve opening the casing or reading chips directly, so one unit may not go back to service. We agree in writing which units can be opened and which tests are off-limits before any work starts.

Yes. We test ECUs, CAN bus and telematics units for vehicles, and connected medical, industrial and consumer devices. Findings can be mapped to ISO/SAE 21434 and UNECE R155 for vehicles, FDA premarket cybersecurity expectations and IEC 81001-5-1 for medical devices, IEC 62443 for industrial systems and ETSI EN 303 645 and the EU Cyber Resilience Act for consumer products.

Yes, and we recommend it. Many of the worst IoT flaws sit in the mobile app or cloud API that controls the fleet, so we test the device, the app and the APIs as one system.

An annual test is a snapshot of one moment. With PTaaS, testing runs alongside your release cycle, findings arrive as they are verified rather than weeks later in one report, and fixes are retested on request, so your security picture stays current.

Every verified finding with its severity, evidence, steps to reproduce and fix guidance, its status from open to retested and closed, the scope of each test cycle, and reports you can download for auditors and buyers.

Yes. Findings can be sent from the portal to Jira or GitHub as tickets or issues with severity and fix guidance, so they are tracked in the same place as the rest of your engineering work.

It is expert-led. Automated checks cover the routine baseline, but every finding is tested by hand and verified before it appears in the portal, and the access-control, business-logic and chained issues that scanners miss are the focus.

Yes. You can export a dated report for any test cycle, with scope, findings and retest results, which auditors accept as evidence of regular independent testing.

Request a test cycle from the platform the day you ship and choose a release test for new features, a full application pentest, or a pipeline and cloud review. The NDA and testing authorisation are kept on file, so testing starts without new paperwork.

When a fix ships you request a retest on the finding and note what changed. The tester verifies it with before-and-after evidence, and the finding is marked fixed and verified. Retests are included, and nothing is closed on trust.

Teams that release often, such as SaaS companies, fintechs and product teams shipping weekly or monthly, and any company whose customers or auditors expect evidence of regular independent penetration testing.

1 July 2025. Existing service provider contracts had until the earlier of their next renewal and 1 July 2026 to align.

CPS 234 covers information security. CPS 230 covers operational risk management, including critical operations, tolerance levels and service providers. They apply together.

APRA-regulated entities such as banks, insurers and superannuation funds. Their suppliers feel the effect through contracts and assurance requests.

Entities must test the effectiveness of controls through a systematic programme, using skilled and functionally independent testers, and escalate and track results.

CPS 234 requires notice to APRA within 72 hours of a material information security incident. CPS 230 has its own 72 hour notice for material operational risk incidents.

That you maintain information security for assets managed by third parties, and obtain assurance that their controls are effective, proportionate to the criticality of the assets.

No. It is general education. Confirm your obligations with qualified counsel or APRA guidance.

Probably, if you have annual turnover above A$3 million, handle health information, trade in personal information or are a government agency. It can also apply to overseas entities carrying on business in Australia.

Reasonable steps to protect personal information from misuse, interference, loss and unauthorised access, and to destroy or de-identify it when it is no longer needed. Reasonable steps include technical and organisational measures.

If you suspect an eligible breach, assess it within 30 days. If likely to cause serious harm, notify the OAIC and affected individuals as soon as practicable.

A statutory tort for serious invasions of privacy, new penalty tiers and infringement notices, a Children’s Online Privacy Code, a mechanism for comparable overseas privacy regimes, and automated decision transparency duties.

For serious or repeated interference with privacy, the maximum is the greater of A$50M, three times the benefit obtained or 30% of adjusted turnover. Lower tiers and infringement notices apply to less serious failures.

They are due to apply from 10 December 2026. Check the latest OAIC guidance as that date approaches.

In stages. Reporting obligations apply from 11 September 2026 and most other obligations, including the essential requirements, from 11 December 2027. Provisions on conformity assessment bodies started earlier, in June 2026.

Yes, software sold or distributed as a product with digital elements is in scope. Pure SaaS is generally outside unless it is a remote data processing solution a product needs in order to function.

Actively exploited vulnerabilities and severe incidents. Send an early warning within 24 hours, a notification within 72 hours and a final report afterwards, to the national CSIRT designated under the Act.

Up to €15M or 2.5% of worldwide annual turnover for breaching the essential requirements, up to €10M or 2% for other obligations, and up to €5M or 1% for incorrect information. Market surveillance authorities can also order recalls.

Many products can follow self-assessment. Important products in Class I and II, and critical products, face stricter routes, and some require an external body. Confirm your class early.

The Act requires regular testing of product security. A documented test, remediation and retest cycle gives you evidence for the technical file and for customers who ask.

It is DIFC Law No. 5 of 2020, the data protection law of the Dubai International Financial Centre, supported by regulations and enforced by the DIFC Commissioner of Data Protection.

Yes. Amendment Law No. 1 of 2025 took effect on 15 July 2025. Reported changes include a private right of action, broader scope and clearer transfer requirements. Read the current text for exact details.

They are the data protection rules of Abu Dhabi Global Market, in force since 14 February 2021 and overseen by the ADGM Office of Data Protection.

Each free zone has its own regime. The federal law applies elsewhere in the UAE, so your location and activities decide which rules matter.

Authorised firms are expected to manage technology and cyber risk under their regulator's systems and controls rules, covering governance, resilience, outsourcing and incident handling.

Neither data protection regime names one, but security of processing is a core duty. Regular expert-led testing is a common way to evidence it.

Entities established in the free zones, and processing connected to them as the laws set out. Check the scope provisions for group companies and cross-border processing.

Directly to financial entities, but vendors providing ICT services to them are affected through contracts, due diligence and, for designated critical providers, direct oversight.

Threat-led penetration testing: an advanced, intelligence-driven test of live production systems that follows a recognised framework, performed by qualified testers.

A 24 hour early warning for significant incidents, an incident notification within 72 hours and a final report within a month, subject to national transposition.

No. DORA is a regulation specific to the financial sector, while NIS2 is a directive covering many sectors. Financial entities are mostly governed by DORA for ICT topics.

Yes, when you offer goods or services to people in the EU or monitor their behaviour in the EU, even if you have no office there.

Not by name. Article 32 requires appropriate security and a process for regularly testing it. Penetration testing is a widely accepted way to meet that expectation.

A personal data breach that is likely to result in a risk to people’s rights and freedoms. Regulators expect you to assess and record every incident, even ones you do not report.

Up to €20 million or 4% of worldwide annual turnover for the most serious infringements, and up to €10 million or 2% for others. Actual fines depend on the case.

Only in certain cases, such as public bodies or large-scale regular monitoring or sensitive data processing. It depends on your activities and scale.

No. HHS does not certify organisations or products. Vendors show readiness through risk analysis, policies, BAAs and independent reports.

Not in so many words. The Security Rule requires risk analysis and periodic evaluation, and penetration testing is a widely accepted way to meet both.

Any person or company that creates, receives, maintains or transmits PHI for a covered entity, including SaaS, hosting and billing vendors.

You assess whether PHI was compromised, then notify affected individuals without unreasonable delay and no later than 60 days after discovery, plus the regulator and sometimes the media.

A framework is guidance you adopt voluntarily, such as NIST CSF. A standard such as ISO 27001 or PCI DSS defines requirements you can be assessed against. A regulation or law, such as GDPR, the Saudi PDPL or DORA, is binding on the organisations it covers. Buyers often ask for evidence against all three, so it helps to know which type you are dealing with.

Start with whatever your first enterprise customers ask for. For many B2B SaaS companies that is SOC 2, for companies selling in Europe or the Middle East it is often ISO 27001, and privacy laws apply as soon as you handle personal data of people in a covered country. One well-scoped framework usually beats three half-finished ones.

Yes. A scoped, expert-led test with clear severity ratings and a retest can serve as technical evidence for several frameworks at once. Each requesting auditor, customer or regulator decides what they accept, so we map the same findings to the control references each one uses.

Yes. The hub includes the Saudi NCA controls (ECC, CCC and DCC), the Saudi, UAE, Omani, Qatari, Bahraini and Egyptian data protection laws, and the DIFC and ADGM regimes, each with its own guide.

Share your systems, your deadline and who is asking. We reply with a fixed-scope quote, and most teams are testing within days once scope and authorisation are agreed.

Only if you want to offer individuals a platform to manage consent across many companies. Companies collecting consent for their own processing need a CMP, not registration.

From November 2026, 12 months after the DPDP Rules were notified on 13 November 2025.

Yes. A CMP produces notices, records consent and handles withdrawal, which supports the notice and consent duties that apply from May 2027.

They share ideas but differ in detail. The DPDP Act has fewer lawful grounds, a notice and consent centre, and a Data Protection Board model. Do not assume GDPR work transfers one to one.

The Schedule to the Act sets maximum penalties: up to ₹250 crore for failing to take reasonable security safeguards; up to ₹200 crore each for failing to notify the Board and affected people of a breach and for breaching the duties on children’s data; up to ₹150 crore for breaching the extra duties of a Significant Data Fiduciary; and up to ₹50 crore for breaching any other provision. The Board sets each amount based on the nature, gravity and duration of the breach.

Yes. Sumrite’s PII data discovery and inventory tool at dpdp.sumrite.com is 100% free. It runs inside your network and scans databases, email, cloud drives, file shares and endpoints for Aadhaar, PAN, passport, mobile and bank account data.

The DPDP Rules were notified on 13 November 2025. Consent manager rules apply from November 2026 and most obligations on data fiduciaries, including security safeguards and breach reporting, apply from May 2027.

Yes, when they process digital personal data outside India in connection with offering goods or services to people in India.

The Act and Rules set expectations such as encryption, access control, monitoring and backups. “Reasonable” depends on risk, so documented testing helps you justify your choices.

We run the full engagement for you and route the formal audit through our empanelled partner, so you deal with one team and get all your work done.

Up to ₹250 crore for failing to take reasonable security safeguards to prevent a personal data breach. Several lines can apply to one incident.

The DPDP Rules were notified on 13 November 2025. Most obligations on Data Fiduciaries, and the penalties for breaching them, apply from May 2027.

The Data Protection Board of India, after an inquiry. Appeals go to the Telecom Disputes Settlement and Appellate Tribunal.

The automated search of systems for personal data, so that every store of it is known, classified and owned.

The Act does not name a tool, but its duties on notice, safeguards, retention and breach reporting cannot be met without knowing where personal data is.

No. It runs on a host inside your own network, so the personal data it finds never leaves it.

They were notified on 13 November 2025 and apply in stages: the Board immediately, consent managers from November 2026, and most other obligations from May 2027.

Have a personal data inventory, notices and consent, Rule 6 security safeguards, a Rule 7 breach reporting process, retention and erasure, children’s data controls and a rights process in place.

Yes, when they process digital personal data in connection with offering goods or services to people in India.

No. ISO 27001 certifies an ISMS against an international standard and results in a certificate. SOC 2 is an auditor’s attestation report on controls. Many companies pursue both.

Annex A lists 93 controls in four themes. You are not required to implement all of them, but you must justify every exclusion in the Statement of Applicability.

The standard does not use that wording, but controls on managing technical vulnerabilities and security testing mean most organisations pursuing ISO 27001 run regular penetration tests.

Three years. In between, the certification body carries out annual surveillance audits, and you recertify at the end of the cycle.

Yes, many teams do, but the risk assessment and Statement of Applicability reward experience. Sumrite can run the gap analysis, testing and retest so your evidence is ready for the assessor.

Cloud service providers and cloud service tenants operating in Saudi Arabia. Your duties depend on your role, so confirm which side you are on first.

CCC extends and complements ECC with cloud-specific requirements. ECC remains the baseline, so organisations in scope for both should plan them together.

CCC-2:2024. Check the NCA website for the latest text and for any updates since.

No. It is a set of control requirements. Whether your evidence is accepted is decided by the NCA or the customer or regulator that requested it.

Its defense requirements include vulnerability management and testing of cloud environments. An expert-led test with a retest is the clearest way to show it.

Not entirely. The provider handles its part, but you remain responsible for your own configuration, access and data.

The Data Cybersecurity Controls issued by Saudi Arabia’s National Cybersecurity Authority. They set cybersecurity requirements for protecting data across its lifecycle.

DCC is designed to work alongside ECC. The document includes an appendix on the relationship, so you can reuse ECC work and add data-specific controls.

No. DCC covers cybersecurity controls for data. PDPL is a personal data protection law. Evidence such as encryption and access logs often helps with both.

No. It is a set of control requirements. Whether your evidence is accepted is decided by the NCA or the requesting customer or regulator.

Testing is the clearest way to show that your data controls work in practice, and it supports the defense requirements.

Saudi government entities and private-sector organisations that own, operate or host critical national infrastructure. The NCA encourages everyone else in the Kingdom to use it, and suppliers often meet it because a customer requires it.

No. It is a set of control requirements. How your compliance is reviewed and accepted is decided by the NCA or the entity that asked for it.

ECC-2:2024, which updates ECC-1:2018. Check the NCA website for the latest text before you plan.

The Cloud and Data Cybersecurity Controls are designed to complement ECC. ECC is the baseline, and CCC or DCC add detail where cloud services or data protection apply.

Yes, its defense domain includes vulnerability management and penetration testing. An expert-led test with a retest is the clearest way to show it.

It depends on where you start. A well-run organisation can be ready in a few months; those building from scratch should plan for longer.

No. It is voluntary guidance. Organisations use it for self-assessment and planning, and there is no official certificate.

A new Govern function, a broader audience beyond critical infrastructure, more attention to supply chain risk and online resources such as implementation examples.

They overlap. CSF is flexible guidance for managing outcomes, while ISO 27001 is a certifiable management system standard. Many teams map between them.

No specific test is mandated, but several outcomes depend on identifying vulnerabilities and verifying safeguards, which testing supports.

Usually the security leader, with executive sponsorship. The Govern function expects clear accountability at a senior level.

Yes. It was issued as Royal Decree 6/2022, and sources we reviewed put the end of the transition period at 5 February 2026, so the law is in its enforcement phase.

The Ministry of Transport, Communications and Information Technology, according to the sources we reviewed. Confirm the current position with your legal adviser.

Sources we reviewed state within 72 hours for breaches that may risk individuals’ rights. Confirm exact triggers with your legal adviser.

It does not use those words. It does require appropriate security, and testing is a common way to evidence it.

No testing firm can grant legal status. Sumrite delivers gap analysis, penetration testing, control validation and a board-ready report for your technical safeguards.

A focused scope usually takes four to six weeks of assessment and testing, then fixes and a retest.

No. It is an industry standard enforced through contracts with card brands and acquiring banks. Non-compliance can lead to fines, higher fees or loss of the ability to take cards.

Yes. Requirement 11.4 requires external and internal penetration testing at least once every 12 months and after significant changes, using qualified and organisationally independent testers.

An SAQ is a self-assessment form many merchants complete. A ROC is a detailed report produced by a Qualified Security Assessor, typically for larger merchants and service providers.

PCI DSS v4.0.1 is the current version. The earlier v4.0 was retired at the end of 2024, and its future-dated requirements became mandatory on 31 March 2025.

Use a compliant payment provider with hosted fields or redirects, never store sensitive authentication data, tokenise card numbers and segment the systems that remain in scope.

Qatar Law No. 13 of 2016, Bahrain Law No. 30 of 2018 and Egypt Law No. 151 of 2020. Saudi Arabia, the UAE and Oman have their own guides.

Sources we reviewed state the executive regulations took effect on 1 November 2025 with a 12-month grace period from 1 November 2025. Confirm the current position with your legal adviser.

Sources we reviewed cite up to QAR 5 million, varying by violation. Confirm the figure and what applies to you with your legal adviser.

They do not use those words. They do require appropriate security, and testing is a common way to evidence it.

Egypt’s regulations reportedly require DPO appointment and registration. Qatar and Bahrain differ, so check with your legal adviser.

Yes. A single scoped assessment of the systems holding personal data can produce one report with sections for each country.

Yes. It took effect on 14 September 2023 and a one-year grace period ended on 14 September 2024, so it is now enforceable. SDAIA is the regulator.

It applies to organisations that process personal data of individuals in Saudi Arabia, including those based abroad. Your legal adviser can confirm how it applies to your situation.

It does not use those words. It does require appropriate security for personal data, and testing is a widely used way to evidence that your safeguards work.

In qualifying cases SDAIA expects notice within 72 hours of becoming aware. Rules vary by risk level, so confirm the exact trigger with your legal adviser.

A focused scope often takes four to six weeks for assessment and testing, then fixes and a retest. Scope and the number of systems drive the timeline.

It is SEBI's Cybersecurity and Cyber Resilience Framework, issued on 20 August 2024. It consolidates earlier cyber circulars for SEBI regulated entities and grades requirements by entity category.

SEBI regulated entities such as stock exchanges, depositories, brokers, depository participants, asset managers and others, with requirements varying by category. Check the circular for your entity type.

VAPT is expected across critical assets, to recognised standards, at a frequency and with submission timelines set by entity category. Findings must be closed and reported through an action taken report.

Where SEBI requires a cyber audit, it must be carried out by an auditor on CERT-In's approved list, who declares no conflict of interest.

The RBI expects board oversight of IT, a defined IT and information security governance structure, regular testing, incident reporting and controls over IT outsourcing. The details are in its master directions, which depend on your category.

Yes. SEBI extended implementation dates more than once after the original start dates. Always check the latest circulars before planning.

Both expect vulnerability assessment and penetration testing as part of a regular cyber testing programme. The exact scope and frequency depend on your entity category.

We run the full engagement for you and route the formal audit through our empanelled partner, so you deal with one team and get all your work done.

A SOC 1 report is an attestation by a licensed CPA firm on controls at a service organisation that are relevant to its customers' financial reporting. Customers' auditors use it to rely on your controls.

SOC 1 covers controls relevant to financial reporting, against control objectives you define. SOC 2 covers security, availability, processing integrity, confidentiality and privacy against fixed AICPA criteria. Many providers need both.

Type I looks at whether controls are suitably designed on one date. Type II also tests whether they operated effectively over a period, commonly six to twelve months for a first report.

IT general controls are the access, change management and operations controls that support the systems producing financial data. Auditors test them because weak ITGCs undermine every automated control above them.

They are controls your customers must perform for your control objectives to be achieved, such as reviewing user access to your platform. The report lists them so customers and their auditors know their part.

They are closely aligned. SSAE 18 is the US standard and ISAE 3402 is the international one, and a single examination can often be reported under both.

No. Penetration testing is not named as a requirement, but many service organisations use it as supporting evidence for logical access and change controls over in-scope systems.

No. It is an attestation report written by an independent CPA firm. There is no certificate and no pass or fail badge, only the auditor’s opinion and any exceptions they list.

Type I checks that controls are designed properly on one date. Type II tests that they operated effectively over a period, usually three to twelve months. Enterprise buyers generally prefer Type II.

Teams that already have solid practices can finish in a few months. Starting from scratch often takes six to twelve months once readiness work and a Type II observation window are included.

The criteria do not use those words, but auditors commonly request penetration test evidence under the monitoring and vulnerability management criteria. Most teams run at least one test per year.

Yes. Many early-stage companies do it to unblock enterprise deals. Keep the scope narrow, automate evidence collection and begin with Security only.

ST4S, Safer Technologies 4 Schools, is a national initiative that assesses the security, privacy and safety of digital products used in schools in Australia and New Zealand.

Education Services Australia (ESA), a ministerial not-for-profit company, runs it with support from Australian state and territory education departments, the Catholic and independent sectors and the New Zealand Ministry of Education.

Most vendors start with the optional Readiness Check, then ask to be prioritised for a full assessment. If selected, you submit questionnaires and evidence, review draft findings and receive a final report.

Security, privacy, interoperability, safety and artificial intelligence. Read the current Vendor Guide on the ST4S website for the detailed requirements.

It is not a law. In practice many schools and education departments check ST4S status before adopting a product, so it often decides whether a sale goes ahead.

The New Zealand Ministry of Education states participation is free. Confirm current terms on the ST4S website, and budget for your own preparation and testing.

Check the current Vendor Guide for the exact requirement. Independent penetration test results are widely used as evidence of security practice and are worth having ready.

The federal law took effect in January 2022. Its executive regulations had not been published in the sources we reviewed, so some operational detail is still pending. Check the current position before relying on any deadline.

No. DIFC and ADGM keep their own data protection regimes inside the free zones. Federal law applies elsewhere in the UAE.

It does not use those words. It does require appropriate security, and testing is a widely used way to evidence that safeguards work.

Waiting carries risk because customers and counterparties already ask for evidence. Testing and fixing now means you only adjust paperwork later.

A scoped assessment of the systems holding personal data, testing, a fix-and-retest cycle and an executive report, usually over four to six weeks of active work.

SIG is from Shared Assessments and covers many risk domains in different depths. CAIQ is from the Cloud Security Alliance and focuses on cloud service controls. Both are widely accepted.

Policies, a security overview, SOC 2 or ISO 27001 evidence where available, a recent penetration test summary with retest, an incident response summary and a list of subprocessors.

From a few days for low-risk vendors to several weeks for critical ones. A prepared pack and a clear point of contact are the biggest accelerators.

Often yes, under NDA. Critical vendors may be asked for the full report and a retest letter.

Yes. Sumrite supplies penetration test reports, retest letters and an evidence pack that back your answers, and stays with you through the buyer’s review.

Yes. The report name the tested assets, the methodology, and the severity of each verified finding. Teams use that pack as technical evidence for DIFC and ADGM data-protection reviews, Central Bank of the UAE information-security expectations, and enterprise vendor questionnaires.

Testing is run by Sumrite's expert team against scoped staging or production assets over an encrypted channel, with an NDA signed before any technical discussion. You get a VAPT report in 48 hours, written for UAE procurement and regulatory reviewers.

A scoped web application or API assessment is delivered in 48 hours, including the report. Broader cloud, network, or red-team work is quoted separately and can take longer. Re-testing of fixed findings is included.

Usually not. Procurement and free-zone reviewers ask for an expert-led penetration test with proof, not a scanner export. Sumrite findings are reproduced by a researcher and written with fix guidance a developer can apply.

CPS 234 requires an APRA-regulated entity to test the security of information assets and to manage third parties. A Sumrite report is evidence an entity can use inside that programme.

We can map relevant findings to Essential Eight strategies such as application control, patching, restricting admin privileges, and multi-factor authentication when those controls are visible in the scoped environment. A full Essential Eight maturity audit of an internal desktop fleet is a different engagement and is quoted separately.

An expert-verified VAPT report in 48 hours, with severity, asset and reproduction steps for each finding, mapped to CPS 234, Essential Eight and the Privacy Act, and a free re-test of fixes.

Yes. Findings that expose personal information are written so privacy and engineering owners can connect them to the Australian Privacy Principles, especially security of personal information under APP 11.

Yes. Sumrite works remotely with teams in every region it serves. The regional pages explain the local compliance context a report is usually mapped to, and the same expert team runs the testing everywhere.

Usually, for vendor security reviews and frameworks that ask for an independent penetration test. Share the questionnaire or contract clause with us and we will confirm the report meets it before you commit.

The technical report is written in English. The regional pages for Saudi Arabia, Germany and France include local-language summaries so reviewers can confirm the scope.

Yes. What reviewers call a VAPT certificate is the signed VAPT report: it names your company, the assets tested, the testing dates, every finding and the retest results, and it is what NCA, SAMA and buyer security reviews accept as evidence. Sumrite issues it in your company name, and where an NCA-registered firm must sign off, routes that step through its local partner while running the whole engagement.

The report is written so control owners can map findings to NCA Essential Cybersecurity Controls and, for financial institutions, the SAMA Cyber Security Framework. It is technical evidence from an expert-led test, written for the reviewer who owns the control.

Yes. Engagements that process personal data can be scoped with PDPL themes in mind: access control, retention, cross-border transfer paths, and processor access. Sumrite signs an NDA before seeing data-flow detail.

The technical report is in English so developers can follow the reproduction steps exactly, with an Arabic executive summary. An Arabic version of this page is at sumrite.com/ar/.

Testing is run by Sumrite's expert team against the hosts you authorise, under an NDA, and the report comes back in 48 hours with an Arabic summary.

Yes. Sumrite has more than 100 clients in Saudi Arabia, including in Riyadh, and delivers VAPT end to end, with formal NCA assessments routed through its local partner firm.

Yes. Findings are mapped to NCA Essential Cybersecurity Controls and, for financial institutions, the SAMA Cyber Security Framework, so control owners can attach the report to their review.

The technical report is in English so developers can follow it exactly, with an Arabic executive summary for leadership and reviewers.

Yes. Sumrite works with clients across the Kingdom, including Jeddah and Dammam.

A model where permissions are attached to roles, such as viewer, editor or admin, and users get a role. The application checks, on every sensitive action, whether the current user's role is allowed to perform it. Access control that enforces this on the server is what stands between an ordinary user and an admin function.

Broken access control: any authenticated user can reach actions and data meant for other roles or other users. That includes admin pages, other customers' records, and privileged API endpoints. It is consistently one of the most common and most serious classes of web application finding.

No. Hiding a button or a menu item only changes what the interface shows. If the server still accepts the request when it is sent directly, the function is open to anyone who knows or guesses the URL or API call. Access control has to be enforced on the server, not in the interface.

Missing RBAC usually means there is no proper check on whether a role may perform an action, so privileged functions are open. IDOR (insecure direct object reference) means a user can reach another user's specific record by changing an identifier. They overlap: both are broken access control, and a test looks for both.

Only partly. A scanner can flag some obvious cases, but understanding which roles exist, what each should be allowed to do, and whether the server enforces it needs a person testing with multiple accounts. This is why access control findings almost always come from manual testing.

Run Sumrite's free scan at scan.sumrite.com for the issues a scanner can see, then reach out to our team for a manual assessment to verify an RBAC failure. Confirming one safely, without touching real data, is expert work.

A manual security test of an application programming interface in which a tester tries to break authentication, access other users' data, abuse business flows and exploit misconfigurations, the way a real attacker would. It goes beyond automated scanning by testing authorisation and logic with real user roles.

A list of the ten most critical API security risks published by OWASP. The current edition, from 2023, covers broken object level authorization, broken authentication, broken object property level authorization, unrestricted resource consumption, broken function level authorization, unrestricted access to sensitive business flows, server-side request forgery, security misconfiguration, improper inventory management and unsafe consumption of APIs.

Broken object level authorization (BOLA, also called IDOR), where changing an ID in a request returns another user's or tenant's data. It is first on the OWASP API list because it is common, easy to exploit and often exposes large amounts of data.

A single API with a few dozen endpoints typically needs three to seven working days of testing, plus reporting and a retest. Large APIs, multiple roles or GraphQL schemas take longer.

API documentation such as an OpenAPI or Postman collection, a test environment that mirrors production, test accounts for each role and at least two tenants or users per role, and a contact who can unblock issues during testing.

No. Scanners find missing headers and known misconfigurations, but they cannot tell whether user A should be allowed to read user B's invoice. Authorisation and business logic flaws, the most damaging API issues, need a human tester.

Testing with no inside information. The tester starts like an external attacker with nothing but what is public, discovering the target as they go. It is realistic for an outsider's view but can miss areas the tester never reaches in the time available.

Testing with full information: source code, architecture, credentials for all roles and configuration. It gives the deepest coverage because the tester can see every path, and often includes source code review. It needs more cooperation and access.

Testing with partial information, typically valid credentials for each user role and some documentation. It balances realism and coverage and is the most common choice for web applications and APIs, because it reflects a logged-in user and reaches the authenticated areas efficiently.

For most web and API tests, grey-box gives the best coverage for the budget. White-box suits high-assurance or compliance-critical systems and code reviews. Black-box suits perimeter and phishing-style assessments where realism matters more than completeness.

It changes which attacker you simulate, not the quality. Giving credentials and docs reflects an attacker who has done reconnaissance or already has a foothold, and it means the limited testing time is spent finding flaws rather than rediscovering what you already know.

Run Sumrite's free scan at scan.sumrite.com for a first look, then talk to us about the right level of access for your goal, whether that is realism, coverage or compliance.

AMBAK stands for Audit Monitoring, Benchmarking, Analysis and Kinetic Interventions. It is a platform CERT-In, India's national cyber security agency under the Ministry of Electronics and IT, launched at the CERT-In SAMVAAD 2026 conference in Goa (27 to 29 April 2026) to support the monitoring, benchmarking and analysis of cyber security audits carried out by CERT-In empanelled auditors.

Audit Monitoring, Benchmarking, Analysis and Kinetic Interventions.

At CERT-In SAMVAAD 2026, CERT-In's national annual conference for security auditing organisations, held from 27 to 29 April 2026 at the BITS Pilani K. K. Birla Goa Campus. The Government of India's PIB release on the conference lists the AMBAK launch among its key outcomes.

Not according to any official source we could find. Some vendor articles describe AMBAK as a blockchain platform with QR-code verification of audit reports from 15 July. As of 27 October 2026, neither the PIB release nor CERT-In's empanelment page mentions blockchain, QR codes or a verification start date, so treat those claims as unconfirmed.

CERT-In has not published any registration, onboarding or compliance requirement for auditees under AMBAK. Your obligations still come from CERT-In's Comprehensive Cyber Security Audit Policy Guidelines of July 2025, the CERT-In Directions of April 2022 and your sector regulator.

Check that the issuing organisation appears on CERT-In's current list of empanelled information security auditing organisations, that the report is issued in that organisation's legal name, that its scope, environment, versions and test dates match the system you rely on, and confirm the report reference directly with the auditor using contact details you found yourself.

No change has been announced. CERT-In's July 2025 audit guidelines call for a cyber security audit at least once a year, and before major changes go live, with sector regulators able to require more.

Only where a regulator, government body or contract asks for it. Common cases are government and public sector systems, websites hosted with government infrastructure, regulated financial entities whose regulator names CERT-In empanelled auditors, and tenders that specify it. For SOC 2, ISO 27001 or customer due diligence, empanelment is not required.

No. CERT-In does not audit or certify individual organisations through empanelment. The empanelled auditor performs the audit and issues the report and, where requested, an audit certificate or compliance letter on its own letterhead.

Look the organisation up on the current list of empanelled information security auditing organisations published on CERT-In's website, and confirm that the report and certificate you will receive are issued in that organisation's name.

CERT-In's audit guidelines call for audits at least once a year and after major changes to critical infrastructure or applications. Your regulator, sector rules or contract may set a different frequency, so follow whichever is stricter.

Yes. Sumrite runs the full engagement, from scoping and manual testing to the retest, and routes the formal attestation through our CERT-In empanelled partner, so you deal with one team from scoping to report.

Not for the services on AWS's permitted list, which includes EC2, RDS, Aurora, CloudFront, API Gateway, Lambda, Lightsail, Elastic Beanstalk, ECS and Fargate, among others. Denial of service, flooding, Route 53 zone walking and subdomain or S3 bucket takeover are prohibited, and red team, phishing and C2 activities need a Simulated Events request at least two weeks in advance.

No. Microsoft no longer requires pre-approval or notification, but testing must follow the Microsoft Cloud Penetration Testing Rules of Engagement. You may only test your own tenant and resources, and denial-of-service testing is not allowed.

No. Google says customers do not need to contact it before testing their own Google Cloud projects, as long as the testing follows the Acceptable Use Policy and Terms of Service and only affects your own projects.

A configuration review checks settings against a benchmark such as CIS. A penetration test goes further and tries to exploit weaknesses, chaining issues such as an exposed service, a leaked key and an over-permissive role to show what an attacker could actually reach.

Over-permissive IAM roles and privilege escalation paths, long-lived access keys, publicly readable storage, exposed management ports and databases, server-side request forgery to the metadata service, secrets in code or environment variables, and gaps in logging.

A single account or subscription with a handful of applications typically takes one to two weeks. Multi-account organisations, Kubernetes clusters and hybrid networks take longer.

Yes. Automated security checks can run on every build, and expert penetration testing can be triggered by releases: when a version reaches production or staging, a release test is requested and testers focus on what changed.

New and changed endpoints, new roles or permissions, changes to authentication or payment flows, new integrations and any change to how tenants are separated. Full application tests then run on a regular cycle.

No. Release tests run alongside the release rather than blocking it, and findings arrive in the platform and in Jira or GitHub as they are verified, so teams fix them in the normal flow of work.

A review of the CI/CD system itself: pipeline permissions, runners, secrets handling, pull requests from forks, build integrity, container images, Kubernetes configuration and infrastructure as code.

No. NCA ECC-2:2024 control 2-11-3-2 requires penetration tests to be conducted periodically and does not set a fixed interval. The entity defines the interval in its approved penetration testing policy under ECC 2-11-1, and must be able to justify that interval to an assessor.

Continuous penetration testing, also called penetration testing as a service (PTaaS), is expert-led pentesting delivered on a rolling basis through a platform instead of as a single annual project. Testers check releases as they ship, verified findings appear live with evidence and fix guidance, and each fix is retested before the finding is closed.

PTaaS can serve as ECC 2-11 evidence when the programme is written into the approved penetration testing policy, covers all internet-facing services named in ECC 2-11-3-1, and produces dated reports with scope, findings and retest results for each cycle. NCA does not certify testing models, so the evidence pack, not the label, is what an assessor reviews.

The NCA Penetration Testing Standard template states that the technical components and services of critical systems should be tested every 6 months. The NCA Vulnerabilities Management Standard template adds monthly vulnerability assessment for internet-facing critical systems and quarterly assessment for internal critical systems.

Continuous pentesting can satisfy SAMA requirements if it includes a full test of customer and internet facing services at least annually, as SAMA Cyber Security Framework section 3.2.4 requires. Sandbox entrants and new licensees under the SAMA Cyber Resilience Fundamental Requirements need penetration testing at least twice a year or after a major or critical change, which a continuous programme meets naturally.

It is when a server copies whatever value arrives in the request's Origin header into the Access-Control-Allow-Origin response header. The browser then treats every website as trusted, so pages on unrelated domains may be allowed to read the API's responses.

No. It is serious when the response also contains Access-Control-Allow-Credentials: true and the API relies on cookies the browser attaches automatically, because logged-in users' data becomes readable by other sites. Without credentials, the exposure is usually limited to data that is already public, and the finding is rated lower.

Only for genuinely public, unauthenticated resources. Browsers refuse to share a response marked with the wildcard when the request includes credentials, so the wildcard cannot be used for authenticated cross-origin calls. For those you need an exact allowlist.

It reduces the risk a lot, because Lax cookies are not sent on cross-site fetch or XHR requests. It does not help when cookies are set with SameSite=None, or when the untrusted origin is a sibling subdomain, which browsers treat as the same site. Fix the CORS policy as well.

When the Access-Control-Allow-Origin value changes per request, a CDN or browser cache could serve a response prepared for one origin to another. Vary: Origin tells caches to keep a separate copy per Origin value.

Inside script-src, it permits inline script blocks, inline event handler attributes such as onclick, and javascript: URLs to execute. Those are the forms that injected scripts usually take, so the policy stops being an effective barrier against cross-site scripting.

It permits JavaScript that converts strings into executable code, such as eval() and the Function constructor, and setTimeout or setInterval called with a string. If untrusted data reaches one of those, the browser will run it as code.

Only a little. You keep benefits such as restricting where images, frames and connections can go, but the script protection that is the main point of a CSP is effectively switched off. Treat it as a policy that still needs real work.

Move inline scripts into external files, then allow the ones you trust with a per-response nonce or a hash, and add 'strict-dynamic' so trusted scripts can load their own dependencies. Modern browsers ignore 'unsafe-inline' when a nonce or hash is present, which helps during migration.

Often yes, but some older libraries and template engines rely on it. Find what depends on it first, update or replace those libraries, and then drop the keyword and test thoroughly.

Sumrite's free scan at scan.sumrite.com reports your Content Security Policy and flags weakening keywords such as 'unsafe-inline' and 'unsafe-eval'. It is an automated first check, not a replacement for an expert review of the whole policy.

The CST Cybersecurity Regulatory Framework (CRF) is a set of cybersecurity requirements and controls for service providers in Saudi Arabia's information and communications technology and postal sectors. The Communications and Information Technology Commission (CITC) issued the CRF in coordination with the National Cybersecurity Authority in 2020, and CITC was renamed the Communications, Space and Technology Commission (CST) in November 2022.

The CST CRF applies to service providers licensed or registered by the Communications, Space and Technology Commission, and to entities otherwise subject to CST, in the ICT and postal sectors. Typical examples are telecom operators, internet service providers, hosting and data-centre providers and cloud service providers holding a CST licence or registration.

The CST CRF uses three cumulative compliance levels: level 1 covers basic security controls, level 2 adds advanced requirements, and level 3 focuses on monitoring efficiency and continuous improvement of level 1 and 2 controls. The Communications, Space and Technology Commission assigns each provider its target compliance level and date based on the provider's criticality.

The CRF text published by CITC includes a Penetration Testing control (4.16) at compliance level 2, which requires providers to define penetration testing requirements, scope and frequency and to report results to trigger remediation. The text gives at least once a quarter on critical information assets as an example frequency, and adds continuous review of the testing process at level 3.

CITC CRF and CST CRF are the same framework under two names. The Communications and Information Technology Commission issued the Cybersecurity Regulatory Framework, and Cabinet Decree No. 235 dated 07/04/1444H (10 November 2022) renamed the regulator the Communications, Space and Technology Commission.

Positive Technologies' Current Cyberthreats in the Middle East report, covering Q2 2025 to Q1 2026, ranked Saudi Arabia the second most targeted country in the region with 12% of successful attacks, behind Israel at 33% and ahead of the UAE at 11%. Positive Technologies also found that Q1 2026 alone accounted for 51% of all attacks recorded in that period.

Government agencies are the most attacked sector in Saudi Arabia, at 35% of successful attacks between Q2 2025 and Q1 2026 according to Positive Technologies. In Q1 2026 government entities accounted for 71% of attacks on Saudi organisations, with manufacturing and industry, retail and services also heavily targeted.

Malware is the most common method in attacks on Saudi organisations, used in 55% of cases according to the Positive Technologies executive summary for Q2 2025 to Q1 2026. Vulnerability exploitation followed at 40%, with DDoS and social engineering at 30% each.

IBM's 2026 Cost of a Data Breach findings for Saudi Arabia put the average breach cost at SAR 27 million. IBM found that breaches starting with exploitation of public-facing applications were the most expensive in the Kingdom, at SAR 34.7 million on average.

A Saudi business can test its defences with manual penetration testing of internet-facing web applications, APIs and networks, phishing simulations against staff, and red team exercises that chain techniques the way real attackers do. Penetration testing is also required periodically under NCA ECC-2:2024 control 2-11.

The average cost of a data breach in Saudi Arabia is SAR 27 million in 2026, according to IBM's Cost of a Data Breach findings for Saudi Arabia released in August 2026. The figure covers breaches that occurred between March 2025 and February 2026.

Financial services has the highest average data breach cost in Saudi Arabia, at SAR 38 million per breach according to IBM's 2026 findings. Industrial organisations followed at SAR 35.4 million and technology companies at SAR 33 million.

Exploitation of public-facing applications causes the most expensive breaches in Saudi Arabia, at SAR 34.7 million on average according to IBM's 2026 findings. Abuse of valid accounts (SAR 33.3 million) and phishing, including voice and SMS phishing (SAR 30.6 million), came next.

Saudi organisations took an average of 226 days to identify a data breach and 59 days to contain it, according to IBM's 2026 Saudi Arabia findings. IBM found that breaches taking more than 200 days to identify and contain cost SAR 32 million on average, against SAR 22 million for faster ones.

The average cost of a data breach in the Middle East is USD 8 million in 2026, according to IBM's Middle East findings released on 3 August 2026. IBM's global average for 2026 is USD 4.99 million, a 12% increase on the previous year.

On its own it is an informational or low-severity finding, not an exploitable flaw. It is reported because it tells attackers which infrastructure you use, and auditors and enterprise security questionnaires expect it to be removed.

It is a listener attribute. Set it to false on each HTTP and HTTPS listener with modify-listener-attributes, not modify-load-balancer-attributes.

No. Browsers and HTTP clients do not depend on the Server response header. The change applies to responses the load balancer sends and does not affect your targets.

The attribute controls the header the ALB itself adds. If your web server or framework (for example nginx or Express) also sets a Server or X-Powered-By header, remove it in that software's configuration too.

Threat-led penetration testing: a controlled red team exercise that mimics the tactics of real threat actors against an entity's live production systems supporting critical or important functions. It is required under Article 26 of DORA for financial entities identified by their competent authority, and follows the TIBER-EU approach.

At least every three years for the financial entities required to perform it. The competent authority can ask for more or less frequent testing depending on the entity's risk profile.

No. Every financial entity in scope, other than microenterprises, needs a digital operational resilience testing programme, including yearly tests of the ICT systems that support critical or important functions. TLPT applies only to entities that meet the criteria in the RTS and are notified by their TLPT authority.

At least 12 weeks under the RTS on TLPT, Delegated Regulation (EU) 2025/1190. Time spent in a limited purple teaming exercise, allowed only in exceptional circumstances with the authority's validation, counts towards the 12 weeks.

Yes, subject to conditions, but financial entities must contract external testers for every third test. Credit institutions classified as significant under the ECB's Single Supervisory Mechanism must use only external testers.

It satisfies part of the yearly testing programme under Articles 24 and 25, which explicitly lists penetration testing alongside vulnerability scans, source code reviews and scenario-based tests. It does not replace TLPT for entities required to perform it.

The Rules were notified on 13 November 2025 with a phased start. Provisions on the Data Protection Board took effect immediately, consent manager rules apply 12 months after notification, and most obligations on data fiduciaries, including security safeguards and breach reporting, apply 18 months after notification, in May 2027.

Rule 6 lists minimum reasonable security safeguards: encryption, obfuscation, masking or virtual tokens; access control; logs, monitoring and review to detect unauthorised access; measures such as backups to keep processing going after a compromise; retention of logs and relevant personal data for one year; security terms in contracts with data processors; and appropriate technical and organisational measures.

Rule 7 requires the data fiduciary to inform affected data principals and the Data Protection Board without delay, and to send the Board a detailed report within 72 hours of becoming aware of the breach, or a longer period if the Board allows.

Rule 6 requires logs and the relevant personal data to be retained for at least one year, for detecting unauthorised access, investigating it and preventing it from recurring, unless another law requires longer.

Significant data fiduciaries must carry out a data protection impact assessment and an audit every 12 months and report the significant observations to the Board, check that algorithmic software does not risk data principals' rights, and follow any data localisation requirements the government specifies.

Not by name. The Rules require safeguards that prevent breaches and detect unauthorised access. Penetration testing is the most direct way to show that encryption, access control and monitoring actually work, and gives you evidence if the Board investigates a breach.

The main difference between ECC-1:2018 and ECC-2:2024 is scope and structure: ECC-2:2024 has 4 main domains and 108 main controls, down from 5 domains and 114 main controls. The National Cybersecurity Authority moved industrial control systems out of ECC into the Operational Technology Cybersecurity Controls (OTCC) and deleted the in-Kingdom hosting sub-control.

ECC-2:2024 deleted sub-control 4-2-3-3, which required an entity's information hosting and storage to be inside Saudi Arabia, and referred data localisation to the National Data Management Office (NDMO). The deletion does not mean data can freely leave the Kingdom, because NDMO rules and sector regulations can still require localisation, and ECC 4-1-3-2 still requires remote-access managed security centres to be located inside Saudi Arabia.

The Industrial Control Systems Cybersecurity domain, main domain 5 in ECC-1:2018, was deleted from ECC-2:2024 and its controls moved to the National Cybersecurity Authority's Operational Technology Cybersecurity Controls (OTCC-1:2022). NCA describes OTCC as an extension to ECC, so organisations running industrial control systems should apply both.

ECC-2:2024 control 1-2-2 requires all cybersecurity positions to be filled by full-time, qualified Saudi cybersecurity professionals. According to Clyde & Co, ECC-1:2018 applied the Saudi-nationals requirement only to senior positions, so ECC-2:2024 widens Saudization to the whole cybersecurity function.

Organisations compliant with ECC-1:2018 do not need to start over for ECC-2:2024, because most controls carried over unchanged. They need to remap control IDs that moved, update policies for the modified controls (MFA, email domain validation, DDoS, cryptography, third parties, Saudization), move industrial control system evidence to OTCC and confirm data hosting decisions against NDMO rules.

NCA ECC-2:2024 control 1-2-2 requires that all cybersecurity positions be filled with full-time and qualified Saudi cybersecurity professionals. The control sits in subdomain 1-2 (Cybersecurity Management) of the National Cybersecurity Authority's Essential Cybersecurity Controls and applies to every entity in ECC scope.

ECC-1:2018 control 1-2-2 required the head of the cybersecurity function and related supervisory and critical positions to be filled with full-time and experienced Saudi cybersecurity professionals. ECC-2:2024 extended the requirement to all cybersecurity positions and changed 'experienced' to 'qualified', according to Appendix C of the ECC-2:2024 document.

ECC 1-2-2 applies to every entity within ECC-2:2024 scope: Saudi government agencies, their affiliated companies and entities inside and outside the Kingdom, and private-sector entities that own, operate or host Critical National Infrastructure. Other private companies are encouraged, but not required, to adopt the Essential Cybersecurity Controls.

NCA's Guide to Essential Cybersecurity Controls Implementation (GECC-2:2026) lists the expected deliverable for ECC 1-2-2 as a detailed list of all personnel, direct or indirect employees and contractors, whose work relates to cybersecurity. The list should show contract type, position titles, job roles, years of experience and academic and professional qualifications.

ECC 1-2-2 governs the entity's own cybersecurity positions, while third-party services such as penetration testing are governed by ECC subdomain 4-1 (Third-Party Cybersecurity). Organisations should still record any contractors doing cybersecurity work in the 1-2-2 personnel list, apply the 4-1 contract and screening requirements, and confirm the treatment of specific outsourced roles with their legal adviser or the National Cybersecurity Authority.

Not by name. Article 32(1)(d) requires a process for regularly testing, assessing and evaluating the effectiveness of your technical and organisational security measures. The UK ICO lists vulnerability scanning and penetration testing as ways to do that, and for internet-facing systems that process personal data, a penetration test is the most common way to evidence it.

GDPR does not set an interval. The ICO says the law does not specify the type of testing or how regularly you should do it. Annual penetration testing of systems that process personal data, plus testing after significant changes, is the common baseline, adjusted to the risk of the processing.

Yes. Article 32 applies to both, and Article 28 requires controllers to use only processors that give sufficient guarantees on security. In March 2025 the ICO fined a processor, Advanced Computer Software Group, £3.07 million after a ransomware attack, citing gaps in multi-factor authentication, vulnerability scanning and patch management.

Breaches of Article 32 fall under Article 83(4), with fines of up to €10 million or 2% of worldwide annual turnover, whichever is higher. Regulators also weigh the security measures you had in place when setting fines for other breaches.

The Digital Omnibus proposal would change breach notification, including a 96-hour deadline and a higher reporting threshold in the Council's position of 21 October 2026, but no change to Article 32 has been reported. It is not yet law, and the current 72-hour rule still applies.

Run Sumrite's free scan at scan.sumrite.com for a first look at your external exposure, then map the systems that process personal data and scope penetration testing around them.

A proposed update to the Security Rule, published in January 2025, would require vulnerability scanning at least every six months and penetration testing at least once every 12 months. As of 2026 it is still a proposal and not yet final, so the explicit requirement is not in force, but the direction of travel is clear.

Covered entities such as health plans, healthcare clearing houses and most healthcare providers, and their business associates, including many software and cloud vendors that handle electronic protected health information on their behalf.

A risk analysis that identifies risks to electronic protected health information, and a periodic technical and non-technical evaluation of safeguards. Neither sets a fixed test or interval, but you must be able to show you assess technical risk and act on it.

It produces concrete evidence that you evaluated technical risk to electronic protected health information, found weaknesses and fixed them. After a breach, being able to show recent testing and remediation supports your position that you had reasonable safeguards.

A class of issue where an application trusts the incoming HTTP Host header as if it were reliable, and reuses it to build URLs, links or redirects. Because the Host header is sent by the client, an attacker can set it to a value the application did not intend.

If the application builds a redirect target from the Host header, a request with a spoofed Host header produces a redirect to that spoofed domain. A victim who follows a link to the real site can be bounced to an attacker-controlled domain, while the path and parameters look legitimate.

The starting link is genuinely on your domain, so it passes the quick checks people and filters make. The redirect then lands the victim on a lookalike page for phishing, or is chained with other flaws such as stolen OAuth tokens or password-reset links that leak to the attacker's host.

Do not build redirects or links from the Host header. Configure the application's canonical domain server-side and use it, validate the incoming Host against an allowlist of expected domains, and reject or return a default response for anything else. Redirect only to relative paths or an allowlist of known URLs.

On its own it is often rated lower severity, but it is a reliable building block. It makes phishing far more convincing and is frequently chained into account takeover through OAuth or password-reset flows, so it is worth fixing rather than dismissing.

Sumrite's free scan at scan.sumrite.com flags redirect and header issues it can detect automatically. Confirming that a redirect is genuinely attacker-controllable, and chaining it, is manual work our team does in a penetration test.

An insecure direct object reference (IDOR) happens when an application uses an identifier supplied by the user, such as a record ID in a URL or API parameter, to fetch data without checking that the user is allowed to access that record. Changing the ID returns someone else's data. In APIs, OWASP calls this Broken Object Level Authorization (BOLA).

No. UUIDs make identifiers hard to guess, which slows enumeration, but they are not access control. IDs leak through logs, emails, shared links and other API responses. The fix is a server-side ownership or permission check on every request; UUIDs are defence in depth.

Create two accounts in different tenants or roles, capture every request that references an object ID, then replay each request with the second account's token. Any response that returns or changes the first account's data is a finding. Automated scanners rarely catch this because they do not know which data belongs to whom.

If personal data was accessed by someone who should not have it, it usually is. Under laws such as India's DPDP Act, GDPR and Saudi PDPL, unauthorised access to personal data can trigger notification duties.

For a clearly scoped web application or API, yes. Sumrite delivers an expert-verified VAPT report in 48 hours for scoped engagements, with a retest of fixes included. Larger scopes take longer.

More roles and tenants, larger API surface, complex business logic, mobile and backend together, internal networks, slow access to credentials and late scope changes.

Usually one to three days, depending on how many findings were fixed.

At least once a year, and again after any significant change to the application, infrastructure or access model. Systems that are internet-facing, handle payments or sensitive data, or change often usually need testing more frequently, such as every six months or per major release.

For a stable, low-risk system, often yes. For a product that ships major features every month, an annual test leaves most of the year's code untested. In that case, add change-driven tests or a continuous testing model on top of the annual test.

PCI DSS requires internal and external tests every 12 months and after significant changes. RBI requires penetration testing of critical systems every 12 months. SEBI CSCRF sets half-yearly VAPT for market infrastructure institutions and qualified stock brokers. SAMA CSF expects annual tests of customer and internet-facing services. DORA requires threat-led testing at least every three years for the firms it applies to.

Typical triggers are a new application or major release, a new payment or authentication flow, new public APIs, a cloud migration or new hosting region, major network or segmentation changes, and mergers or acquisitions. Define your own list in advance, because PCI DSS assessors check you followed it.

Scans are cheap and automated, so run them far more often: at least quarterly, and monthly or continuously for internet-facing assets. Penetration tests are manual and deeper, so they run annually and after significant changes.

Testing from outside your network, against your internet-facing systems: websites, applications, APIs, VPNs, email and exposed infrastructure. It simulates an attacker on the internet with no prior access, and answers how well your perimeter holds up.

Testing from inside your network, usually from an assumed-breach position such as a standard employee device or a foothold an attacker might gain. It simulates what someone could do once inside: move laterally, escalate privileges and reach sensitive systems and data.

Most organisations do. External testing alone assumes the perimeter never fails, which is unrealistic given phishing, stolen credentials and supply-chain compromise. Internal testing shows how far a breach would spread. Together they cover the full picture.

If you have never tested, start with external to close the most exposed, internet-reachable issues, then add internal to understand blast radius. Compliance or a recent incident may change the priority.

Yes. In cloud environments the boundary is identity more than network location, so 'internal' often means an assumed-breach test from a low-privilege account or workload. The principle, test both the outside view and the post-foothold view, still holds.

Run Sumrite's free scan at scan.sumrite.com for your external exposure, then talk to us about the internal, assumed-breach testing a scanner cannot do.

Annex A control 8.8 of ISO/IEC 27001:2022, 'Management of technical vulnerabilities'. It requires an organisation to obtain information about the technical vulnerabilities of its information systems, evaluate its exposure, and take suitable measures such as patching, mitigating or accepting the risk.

The standard does not fix an interval. Common practice is regular vulnerability scanning, at least annual penetration testing of key systems, and testing after significant changes, with the cadence justified by your risk assessment.

A documented vulnerability management process, an asset inventory, scan and penetration test reports, a risk-rated register of findings, remediation records with owners and dates, and evidence of retesting. The auditor checks that the cycle runs, not just that one test happened.

A.8.8 (technical vulnerabilities) works with A.8.9 (configuration management), A.8.25 to A.8.29 (secure development and testing) and A.5.7 (threat intelligence). Testing evidence often supports several of these at once.

Run Sumrite's free scan at scan.sumrite.com for a first look, then set up scanning and penetration testing mapped to A.8.8 with findings tracked to closure.

ISO 27001 controls can be reused for NCA ECC-2:2024 compliance where they meet the ECC requirement, because both frameworks cover governance, risk, people, technical controls, continuity and suppliers. ISO 27001 evidence such as policies, risk registers, asset inventories and internal audit reports often supports ECC controls directly, but ECC adds Saudi-specific and prescriptive requirements that ISO 27001 does not contain.

An ISO 27001 certificate does not mean an organisation is NCA ECC compliant. ECC-2:2024 is a mandatory national baseline assessed by the National Cybersecurity Authority through self-assessment, compliance-tool reports and audit visits, and it includes requirements such as Saudi staffing of all cybersecurity positions (ECC 1-2-2) that ISO 27001 does not address.

The ECC-2:2024 document published by the National Cybersecurity Authority does not include a mapping to ISO 27001 or other international standards. NCA has published framework mappings for some other control sets; its page for the Critical Systems Cybersecurity Controls (CSCC-1:2019) says those controls were mapped to ISO 27001:2013, NIST CSF v1.1, PCI DSS v3.2.1 and the CIS Controls.

NCA ECC-2:2024 requirements that ISO 27001 does not cover include full-time, qualified Saudi professionals in all cybersecurity positions (ECC 1-2-2), a cybersecurity department independent of IT (ECC 1-2-1), a cybersecurity supervisory committee (ECC 1-2-3), periodic penetration testing of all internet-facing services (ECC 2-11), and in-Kingdom location of remote-access managed security operations centres (ECC 4-1-3-2).

ISO 27001:2022 Annex A contains 93 controls in four themes: organisational (37), people (8), physical (14) and technological (34), according to ISACA. NCA ECC-2:2024 contains 108 main controls and 92 subcontrols across 4 main domains and 28 subdomains. The two sets are structured differently, so a mapping should be done requirement by requirement, not by count.

ISO 27001 does not use the words penetration test. It requires you to manage technical vulnerabilities according to your risks. In practice most certification auditors expect regular vulnerability scanning and an independent penetration test of internet-facing and critical systems as evidence that Annex A 8.8 is working.

Mainly A.8.8 Management of technical vulnerabilities, A.8.29 Security testing in development and acceptance, and A.5.35 Independent review of information security. Findings also feed your risk assessment and risk treatment plan under clauses 6.1 and 8.

The standard sets no frequency. A common, defensible baseline is continuous or quarterly vulnerability scanning, an annual penetration test of internet-facing and critical systems, and additional testing after significant changes. Write the cadence into your policy and follow it.

No. The certification body audits your management system and samples evidence. It does not perform technical testing. That is why your own VAPT reports, tickets and retest results are the evidence it relies on.

It can support A.8.8, but A.5.35 asks for independent review, and many auditors and customers expect an external tester for the annual penetration test. Internal testing works well alongside it, for example in the development cycle under A.8.29.

A security test of an application built on a large language model, such as a chatbot, a retrieval-augmented generation (RAG) assistant or an AI agent. Testers try to make the model leak data, ignore its instructions, misuse its tools or harm the systems around it, using the OWASP Top 10 for LLM Applications as the baseline.

OWASP's list of the ten most critical security risks for LLM applications. The 2025 edition covers prompt injection, sensitive information disclosure, supply chain, data and model poisoning, improper output handling, excessive agency, system prompt leakage, vector and embedding weaknesses, misinformation and unbounded consumption.

No. Prompt injection gets the headlines, but the expensive findings usually come from what the model is connected to: retrieval that ignores user permissions, agents with write access they do not need, and model output passed straight into a browser, database or shell.

Yes. The chat interface sits on top of ordinary web pages, APIs, authentication and cloud services. Most real-world AI incidents still involve a classic flaw such as broken access control or an exposed key. A good LLM test covers both layers.

A single chatbot or RAG assistant with a few integrations typically takes one to two weeks of testing. Agents with many tools, several user roles or multiple models take longer, and a retest is planned after fixes.

Yes. Sumrite tests LLM features together with the web application, APIs and cloud services around them, maps every finding to the OWASP LLM Top 10 and includes a retest.

The OWASP Mobile Application Security Verification Standard. It defines the security controls a mobile app should meet, grouped into storage, cryptography, authentication and authorization, network communication, platform interaction, code quality, resilience against reverse engineering and privacy. The companion OWASP MASTG explains how to test each one.

MASVS says what a secure app should do; the Mobile Application Security Testing Guide (MASTG) describes how to test it on Android and iOS, with tools and techniques for each control.

Static analysis of the app package, dynamic testing on rooted or jailbroken devices, traffic interception and testing of the back-end APIs, checks of local data storage, authentication and session handling, platform features such as deep links and permissions, and, where needed, resilience against tampering and reverse engineering.

Yes, if you ship both. The platforms store data, handle permissions and protect binaries differently, and cross-platform frameworks still produce separate native packages. Issues found on one often do not exist on the other, and the reverse.

The APIs need testing too. Most serious mobile findings are in the back end the app talks to, such as other users' data returned by an API. A good mobile test includes the APIs the app calls.

Typically five to ten working days for one app on both platforms with its APIs, plus reporting and a retest. Apps with payments, many roles or strong anti-tampering take longer.

Yes. The SAMA Cyber Resilience Fundamental Requirements (CRFR), which apply to entities entering SAMA's Regulatory Sandbox or seeking a licence, require penetration testing at least twice a year or after a major or critical change. Licensed banks, insurers and financing companies fall under the SAMA Cyber Security Framework, whose section 3.2.4 requires annual review and penetration tests of customer and internet facing services, which includes mobile banking apps.

No. The SAMA Open Banking Lab provides conformance suites that certify an API works as the Open Banking Framework specifies. Conformance testing checks that the API behaves correctly for valid requests, while an API penetration test checks whether an attacker can abuse consent, tokens or object identifiers to reach data or payments they should not.

A mobile app penetration test should follow the OWASP Mobile Application Security Verification Standard (MASVS) and the OWASP Mobile Application Security Testing Guide (MASTG). The backend APIs the app calls should be tested against the OWASP API Security Top 10 (2023), because most serious mobile findings sit in the API rather than on the device.

The SAMA Cyber Resilience Fundamental Requirements (CRFR) ask entities to implement shielding techniques such as code obfuscation, white box cryptography and anti-tampering. The CRFR also states that inactive sessions should not exceed 5 minutes for applications and underlying infrastructure, and a mobile penetration test should verify both.

The Saudi Central Bank (SAMA) issued the first release of the Open Banking Framework, covering the Account Information Service (AIS), in November 2022. SAMA issued the second release, covering the Payment Initiation Service (PIS), in 2024, and announced in March 2026 that it had started licensing fintech companies to provide open banking services.

NCA CCC-2:2024 is the second version of the Cloud Cybersecurity Controls issued by Saudi Arabia's National Cybersecurity Authority. CCC-2:2024 extends the Essential Cybersecurity Controls (ECC) with cloud-specific requirements for cloud service providers (CSPs) and cloud service tenants (CSTs), across 4 main domains and 24 subdomains.

NCA CCC-2:2024 applies to cloud service tenants that are Saudi government agencies, their companies and sub-entities, or private-sector owners, operators or hosts of Critical National Infrastructure, when they use or plan to use cloud services. CCC-2:2024 also applies to cloud service providers that serve those tenants, whether or not the provider falls within ECC scope itself.

In NCA CCC-2:2024, a cloud service provider (CSP) offers cloud services and must meet 37 main controls and 94 subcontrols, while a cloud service tenant (CST) uses cloud services and must meet 18 main controls and 26 subcontrols. Control IDs show the track: 'P' marks provider controls and 'T' marks tenant controls, for example 2-9-P-1 and 2-9-T-1.

NCA CCC-2:2024 control 2-10-P-1-1 requires cloud service providers to run penetration tests covering the Cloud Technology Stack at least once every six months, in addition to ECC control 2-11-3. CCC-2:2024 has no separate penetration testing control for cloud service tenants, but tenants remain bound by ECC 2-11 and by CCC 2-9-T-1 on vulnerability management.

NCA CCC-2:2024 deleted the earlier in-Kingdom hosting subcontrols 2-3-P-1-10 and 2-3-P-1-11 and referred data localisation to the National Data Management Office (NDMO) at SDAIA. Cloud service providers and tenants should consult NDMO rules and sector regulators before deciding where data can be hosted.

The Critical Systems Cybersecurity Controls (CSCC-1:2019) are issued by Saudi Arabia's National Cybersecurity Authority to extend the Essential Cybersecurity Controls (ECC) for national critical systems. CSCC-1:2019 contains 4 main domains, 21 subdomains, 32 main controls and 73 subcontrols, and is mandatory for systems deemed critical by the organisations that own or operate them.

NCA CSCC applies to organisations that own or operate critical systems, including government organisations inside the Kingdom or abroad and subsidiaries of government or private organisations. ECC compliance is a prerequisite: CSCC-1:2019 states that organisations must continuously comply with ECC to be fully compliant with CSCC.

Under NCA CSCC-1:2019, a critical system is one whose failure, unauthorised change or unauthorised access could affect service availability or cause economic, financial, security or social harm at national level. NCA's criteria include harm to national security or the Kingdom's reputation, financial loss above 0.01% of GDP, impact on services used by more than 5% of the population, loss of life, disclosure of Top Secret or Secret data, and impact on vital sectors.

NCA CSCC-1:2019 control 2-10-2 requires penetration tests on critical systems at least once every six months. Control 2-10-1 requires the scope to cover all of the critical systems' technical components and the tests to be run by a qualified team, and control 2-9-2 requires vulnerability assessments at least once a month.

NCA CSCC-1:2019 control 2-2-1-1 prohibits remote access to critical systems from outside the Kingdom of Saudi Arabia. Any testing access to critical systems should therefore originate inside Saudi Arabia, under access the organisation controls and monitors.

The NCA ECC-2:2024 checklist covers 108 main controls and 92 subcontrols across 4 main domains and 28 subdomains. Domain 1 (Cybersecurity Governance) has 35 main controls, Domain 2 (Cybersecurity Defense) 61, Domain 3 (Cybersecurity Resilience) 4, and Domain 4 (Third-Party and Cloud Computing Cybersecurity) 8.

The National Cybersecurity Authority states in ECC-2:2024 that it will issue an ECC-2:2024 Assessment and Compliance Tool to organise assessment, and NCA already publishes Excel assessment tools for other control sets such as OTCC. Until you have the official tool, a working checklist built from the ECC-2:2024 control text, with evidence and owner columns, is the practical substitute.

An NCA ECC control is usually proven by three kinds of evidence: an approved document that defines the requirement, operating records that show it is implemented, and a dated record of the periodic review. Technical controls such as ECC 2-10 and ECC 2-11 also need scan outputs, penetration test reports, remediation trackers and retest results.

Completing an NCA ECC checklist does not produce a certificate, because ECC-2:2024 is not a certifiable standard. The National Cybersecurity Authority assesses compliance through self-assessment, compliance-tool reports and/or field audit visits, so the checklist is a tool for readiness and continuous compliance, not a certification step.

An NCA ECC checklist should be reviewed at least as often as the periodic reviews it records, and in any case before each self-assessment or audit. Most ECC-2:2024 subdomains end with a control requiring periodic review of their own implementation, so an annual full pass with quarterly updates for technical controls is a sensible rhythm.

NCA ECC compliance means implementing the National Cybersecurity Authority's Essential Cybersecurity Controls (ECC-2:2024), the minimum cybersecurity baseline for government entities and Critical National Infrastructure operators in Saudi Arabia. ECC-2:2024 contains 4 main domains, 28 subdomains, 108 main controls and 92 subcontrols. Compliance must be ongoing and continuous, not a one-off project.

NCA ECC-2:2024 is mandatory for Saudi government agencies (ministries, authorities and establishments), their affiliated companies and entities inside and outside the Kingdom, and private-sector entities that own, operate or host Critical National Infrastructure. The National Cybersecurity Authority encourages every other organisation in Saudi Arabia to adopt the controls as good practice.

There is no NCA ECC certificate, and ECC-2:2024 is not a certifiable standard in the way ISO 27001 is. The ECC-2:2024 document says the National Cybersecurity Authority assesses compliance through self-assessment, periodic reports from its compliance tool and/or on-site audit visits. A consultant who promises an ECC certificate is describing something NCA does not issue.

NCA ECC-2:2024 contains 108 main controls and 92 subcontrols, organised into 4 main domains and 28 subdomains. Domain 1 (Cybersecurity Governance) holds 35 main controls, Domain 2 (Cybersecurity Defense) 61, Domain 3 (Cybersecurity Resilience) 4 and Domain 4 (Third-Party and Cloud Computing Cybersecurity) 8.

NCA ECC-2:2024 requires penetration testing under subdomain 2-11. The scope must cover every service provided externally via the internet and its technical components, including infrastructure, websites, web applications, mobile apps, email and remote access, and tests must be conducted periodically. Vulnerability management is a separate requirement under subdomain 2-10.

An NCA ECC gap assessment compares an organisation's current cybersecurity controls with the National Cybersecurity Authority's Essential Cybersecurity Controls (ECC-2:2024) and records, for each control, whether it is met, partly met or not met, with evidence. The output is a scored control register and a prioritised remediation roadmap.

The duration of an NCA ECC gap assessment depends on the number of entities, sites and systems in scope and on how organised the existing evidence is. A single entity with documented policies and an up-to-date asset inventory moves much faster than a group with several affiliates and no central evidence store. Agree scope first, then plan interviews and evidence reviews around it.

An ECC gap assessment is not an NCA audit. The gap assessment is an internal or consultant-led review that prepares an organisation, while the National Cybersecurity Authority assesses compliance itself through self-assessment, periodic reports from its compliance tool and/or on-site audit visits. There is no ECC certificate at the end of either.

An NCA ECC gap assessment needs evidence that each control is defined, implemented and reviewed: approved policies and procedures, organisation charts, committee minutes, asset inventories, configuration records, vulnerability and penetration test reports, and review reports. NCA's Guide to ECC Implementation (GECC-2:2026) lists the expected deliverables for each control.

An ECC gap assessment does not have to include penetration testing, but the penetration testing control (ECC 2-11) and the vulnerability management control (ECC 2-10) can only be scored as met with current test reports. Many organisations run an external penetration test alongside the gap assessment so Domain 2 can be scored on real results rather than claims.

The NCA penetration testing requirements sit in ECC-2:2024 subdomain 2-11. Entities must define, document and approve penetration testing requirements (2-11-1), implement them (2-11-2), include every service provided externally via the internet and its technical components in scope and test periodically (2-11-3), and periodically review the implementation (2-11-4).

NCA ECC-2:2024 control 2-11-3-2 requires penetration tests to be conducted periodically and leaves the interval to the entity's approved policy. The National Cybersecurity Authority's published Penetration Testing Policy template sets at least once a year for telework systems and internet-facing services, and at least every six months for critical systems.

The NCA penetration testing policy template is a model policy published by the National Cybersecurity Authority in its cybersecurity toolkits, in English and Arabic, alongside a separate Penetration Testing Standard template. Both are illustrative documents with placeholders that an organisation must adapt and approve, and both were written to align with ECC-1:2018 and CSCC-1:2019.

A vulnerability scan is not enough for NCA ECC 2-11. ECC-2:2024 treats vulnerability management (2-10) and penetration testing (2-11) as separate subdomains, and penetration testing requires simulated attacks against the in-scope internet-facing services. A scan supports 2-10; a manual penetration test closes 2-11.

An NCA assessor expects an approved penetration testing policy or standard, a test plan, a scope reconciled to the ECC 2-1 asset inventory, the test report, a remediation tracker, retest results and a dated record of the periodic review under ECC 2-11-4. External testers also need contracts with the cybersecurity clauses required by ECC 4-1-2.

NCA ECC-2:2024 is the National Cybersecurity Authority's national baseline of 108 main controls for government entities and private entities that own, operate or host Critical National Infrastructure. The SAMA Cyber Security Framework is the Saudi Central Bank's sector framework for banks, insurers, financing companies, credit bureaus and the financial market infrastructure, assessed against a maturity model with a level 3 minimum.

Every Saudi bank must comply with the SAMA Cyber Security Framework because it applies to all SAMA Member Organizations. A bank must also comply with NCA ECC-2:2024 when it owns, operates or hosts Critical National Infrastructure, or when it is a government-affiliated entity, so many large financial institutions work to both frameworks.

One penetration testing programme can satisfy both NCA ECC 2-11 and SAMA CSF 3.2.4 if its scope covers every internet-facing service listed in ECC 2-11-3-1 and every customer and internet-facing service under SAMA CSF 3.2.4. The programme should test at least annually, follow up with retests, and map each finding to both control references in the report.

NCA ECC-2:2024 control 2-11-3-2 requires penetration tests to be conducted periodically and leaves the interval to the entity's approved requirements. SAMA CSF 3.2.4 is more specific and requires annual review and penetration tests of customer and internet-facing services, so a dual-compliance programme should test at least annually.

Neither the National Cybersecurity Authority nor SAMA publishes an official crosswalk in the ECC-2:2024 or SAMA Cyber Security Framework texts. Financial institutions usually build their own mapping in a single control register and record, for each control, the ECC reference, the SAMA CSF subdomain and the shared evidence.

Not by name. The directive requires entities to take appropriate risk-management measures and to have policies to assess their effectiveness (Article 21). Penetration testing is one of the methods named in the technical implementing rules as a way to do that, so for most entities it is the practical route to compliance rather than an explicit mandate.

Essential and important entities in sectors such as energy, transport, banking, health, drinking and waste water, digital infrastructure, public administration, space, postal services, waste management, chemicals, food and manufacturing. Size matters too: generally medium and large organisations, with some entities in scope regardless of size.

It mainly affects supervision and penalties. Essential entities face proactive supervision and higher maximum fines; important entities face mainly reactive supervision. Both must meet the same Article 21 risk-management duties.

For essential entities, fines up to at least EUR 10 million or 2% of total worldwide annual turnover, whichever is higher. For important entities, up to at least EUR 7 million or 1.4% of worldwide annual turnover. Management can also be held accountable.

The directive sets no fixed interval. A defensible baseline is at least annual testing of the systems supporting your essential services, plus testing after major changes and when the threat picture shifts, with the cadence justified by your risk assessment.

Run Sumrite's free scan at scan.sumrite.com for the obvious exposures, map the systems behind your essential services, and plan annual penetration testing and effectiveness reviews around them.

Internal and external penetration tests are required at least once every 12 months and after any significant infrastructure or application upgrade or change (Requirements 11.4.2 and 11.4.3). Segmentation controls must be tested at least every 12 months, or every six months for service providers (11.4.5 and 11.4.6).

A qualified internal resource or a qualified external third party, as long as the tester is organisationally independent of the systems being tested. The tester does not need to be a QSA or an ASV.

No. ASV scans are quarterly external vulnerability scans under Requirement 11.3.2. A penetration test under 11.4 is a manual attempt to exploit weaknesses, including from inside the network and through applications. You need both.

Testing that proves the network controls separating the cardholder data environment from out-of-scope systems actually work. If you use segmentation to reduce PCI scope, it must be tested at least annually, every six months for service providers, and after any change to segmentation.

Requirement 11.4.4 requires exploitable vulnerabilities to be corrected according to your risk assessment, and the test to be repeated to verify the corrections. Assessors expect to see the retest evidence, not just the original report.

PCI DSS v4.0.1. Version 3.2.1 was retired in 2024, and the requirements that were future-dated in v4.0 became mandatory on 31 March 2025.

A PDPL compliance checklist should cover scope and governance, a lawful basis for every purpose, privacy notices, data subject rights, records of processing, impact assessments, security safeguards, breach notification, processor contracts and transfers outside Saudi Arabia. Each item should name the evidence a controller would show the Saudi Data & AI Authority (SDAIA) on request.

Saudi PDPL records of processing must be kept for as long as the processing continues and for five years after it ends. The record covers purposes, categories of personal data and data subjects, recipients, retention periods, transfers outside the Kingdom and, where possible, security measures.

A Saudi business must answer a PDPL data subject request within 30 days under the PDPL Implementing Regulation. The deadline can be extended by up to a further 30 days where the request needs unusual effort or several requests arrive, provided the individual is told in advance with reasons.

The Saudi PDPL does not name penetration testing, but Article 19 requires appropriate organisational, administrative and technical measures to protect personal data. SDAIA penalised controllers for missing safeguards in the decisions reported in January 2026, so a recent penetration test of systems holding personal data is the clearest evidence for the security items on a PDPL checklist.

Sumrite provides this PDPL compliance checklist as a spreadsheet on request through its contact page, with columns for owner, evidence and status. The spreadsheet follows the same order and article references as the published checklist.

Yes. Article 29 of the Saudi Personal Data Protection Law (PDPL) allows personal data to be transferred outside the Kingdom for defined purposes, provided the transfer does not prejudice national security or the Kingdom's vital interests and only the minimum data needed is sent. The transfer must also rely on adequacy or on appropriate safeguards under SDAIA's Regulation on Personal Data Transfer outside the Kingdom.

SDAIA's Standard Contractual Clauses are fixed contract templates, version 1.0 issued in September 2024, for transferring personal data out of Saudi Arabia. The clauses come in four modules: controller to controller, controller to processor, processor to processor and processor to controller. The parties may only complete the blanks, and the importer submits to Saudi law and courts.

A PDPL transfer risk assessment is required under Article 7 of SDAIA's Transfer Regulation when a transfer relies on one of the exemption cases in Article 4, and when sensitive data is transferred outside the Kingdom on a continuous or widespread basis. The assessment covers the purpose and legal basis, the nature of the transfer, the safeguards, data minimisation, potential harms and mitigating controls.

As of November 2026, the Saudi PDPL has no general rule requiring personal data to be stored in Saudi Arabia, although the PDPL does not override localisation requirements in other laws. SDAIA's October 2026 draft amendments to the PDPL Implementing Regulation propose an express in-Kingdom storage duty in Article 23, but that draft is a proposal and not law.

Article 3 of SDAIA's Transfer Regulation requires SDAIA to publish a list of countries and international organisations with adequate protection, reviewed at least every four years. Law-firm analyses published in March 2025 and January 2026 reported that the list had not yet been issued, so most transfers rely on Standard Contractual Clauses or binding common rules.

The maximum Saudi PDPL fine for a general violation is SAR 5 million per violation under Article 36, and SDAIA's committees can issue a warning instead. The fine can be doubled for a repeat violation. Disclosing sensitive personal data with intent to harm or for personal benefit carries up to two years' imprisonment and a fine of up to SAR 3 million under Article 35.

On 16 January 2026 the Saudi Press Agency reported that SDAIA's committees for reviewing PDPL violations had issued 48 decisions confirming violations and enforcing penalties on data controllers during the previous year. The decisions covered unlawful collection and processing, disclosure without legal justification, missing safeguards and marketing without consent.

The PDPL breach notification deadline is 72 hours from becoming aware of a personal data breach, under Article 24 of the PDPL Implementing Regulation. Controllers notify SDAIA through the National Data Governance Platform, and notify affected individuals without undue delay where the breach may harm them.

A company has five days to respond after being notified of an alleged PDPL violation, according to Clyde & Co's March 2026 analysis of the Rules of Procedure for SDAIA's violation committees. Committee decisions are notified within 15 days of issue, and appeals go to the competent court within 60 days of notification.

Yes. A Saudi PDPL penalty decision can be ordered to be published at the violator's expense, and a court can also confiscate funds obtained through the violation. Individuals harmed by a violation can separately claim compensation for material or moral damage.

On 5 November 2026. SDAIA published the draft on the Istitlaa public consultation platform on 6 October 2026.

No. They are draft amendments under public consultation. As drafted, they would take effect 60 days after publication in the Official Gazette, once approved.

The draft adds an express requirement in Article 23 for controllers to store personal data inside the Kingdom, while still allowing transfers and disclosures abroad under the PDPL and its regulations. Law firms reading the draft disagree on whether that means keeping a local copy of data you also process offshore, so read the text and comment if the wording affects you.

The draft keeps notification to SDAIA within 72 hours of becoming aware of a breach, but removes the current test of whether harm is likely. If adopted, more incidents would need to be reported to SDAIA. Keep following the current rule until a new text is in force.

Under the draft, public entities, controllers whose core activity is processing personal data, controllers processing sensitive data or data of people lacking legal capacity, and controllers that transfer or disclose personal data outside the Kingdom.

Through the Istitlaa public consultation platform, before 5 November 2026, with each comment tied to a specific article and proposed wording.

No. The Saudi Personal Data Protection Law (PDPL) shares the GDPR's core ideas, such as lawful processing, data subject rights, records of processing and 72-hour breach notice, but it differs in important details. The PDPL treats consent as the main legal basis, has no general right to object, sets its own transfer rules under SDAIA, and adds criminal penalties for unlawful disclosure of sensitive data.

GDPR compliance does not automatically make a company compliant with the Saudi PDPL. A GDPR programme covers much of the groundwork, but the PDPL needs Saudi-specific work on legal bases, consent records, sensitive-data categories, records of processing kept for five years after processing ends, SDAIA registration and transfers out of the Kingdom.

Saudi PDPL administrative fines reach SAR 5 million per violation under Article 36, and can be doubled for repeat violations. GDPR fines reach EUR 20 million or 4% of worldwide annual turnover, whichever is higher, under Article 83(5). The PDPL also allows up to two years' imprisonment for disclosing sensitive data with intent to harm, under Article 35.

A European company can send Saudi personal data to the EU only under Article 29 of the Saudi PDPL and SDAIA's Regulation on Personal Data Transfer outside the Kingdom. In practice that usually means SDAIA's Standard Contractual Clauses or binding common rules, a transfer risk assessment where required, and sending only the minimum data needed.

The Saudi PDPL does not require a foreign controller to appoint a representative in Saudi Arabia, unlike GDPR Article 27 for non-EU controllers. Foreign controllers are still in scope when they process Saudi residents' personal data, and SDAIA's National Data Governance Platform offers a registration route for entities outside the Kingdom.

Penetration testing cost in Saudi Arabia depends on scope rather than a standard price: the number and complexity of assets, the test perspective, the regulatory mapping required, delivery constraints and whether a retest is included. A reliable figure only comes from a quote against a defined asset list.

Penetration testing quotes in Saudi Arabia vary because vendors price different scopes and methods. One quote may cover an automated scan of a single URL, another a manual, authenticated test of every NCA ECC 2-11-3-1 component with a retest and control-mapped evidence. Giving every vendor the same written scope makes quotes comparable.

NCA ECC compliance changes the scope of a penetration test rather than its unit price. Control 2-11-3-1 requires all internet-facing services and their components to be tested, including email and remote access, and the evidence must map to the controls. A test built for ECC therefore covers more assets than a single-application test.

A Saudi penetration testing quote needs the asset list (URLs, APIs, app builds, IP ranges), the number of user roles, the test perspective, the frameworks the report must map to, any on-site or production-window constraints, the reporting language and the target date. With that brief, vendors can quote like for like.

Continuous penetration testing is not always cheaper than annual testing in Saudi Arabia, but it spreads effort across the year and tests changes as they ship. Organisations that release often usually get more coverage per riyal from a continuous programme than from repeated one-off engagements.

Riyadh businesses mainly answer to three regulators headquartered in the city: the National Cybersecurity Authority (NCA), the Saudi Central Bank (SAMA) and the Communications, Space and Technology Commission (CST). NCA's Essential Cybersecurity Controls require periodic penetration tests of internet-facing services, and SAMA's Cyber Security Framework requires annual penetration tests of customer and internet-facing services.

A Riyadh company does not need a penetration testing firm with a Riyadh office, because most external testing is delivered remotely. What a Riyadh company does need is a testing entity registered with the National Cybersecurity Authority, plus a plan for on-site or in-Kingdom access when internal networks or critical systems are in scope.

A regional headquarters in Riyadh is not automatically in scope of NCA ECC, but many regional headquarters sell to Saudi government entities or regulated firms. Those customers are required to manage third-party cybersecurity risk under NCA ECC 4-1, so they routinely ask suppliers for recent penetration test evidence.

A Riyadh organisation in scope of NCA ECC-2:2024 must test internet-facing services periodically at an interval set in its approved policy, and a SAMA-regulated organisation must test customer and internet-facing services annually. Testing again before major releases is the usual practice for both.

A Riyadh penetration test usually covers the components named in NCA ECC 2-11-3-1: infrastructure, websites, web applications, smartphone and tablet applications, email and remote access. Riyadh financial institutions add open banking and payment APIs, and government-linked entities often add internal networks and critical systems.

Penetration testing is mandatory for organisations in scope of the National Cybersecurity Authority's Essential Cybersecurity Controls (ECC-2:2024), which require periodic tests of every internet-facing service under subdomain 2-11. SAMA-regulated financial institutions must also put customer and internet-facing services through an annual review and penetration test under SAMA CSF 3.2.4. Other private companies are not covered by those two frameworks but are usually asked for test evidence by regulated customers.

NCA ECC 2-11-3-1 requires the penetration testing scope to include all services provided externally via the internet and their technical components: infrastructure, websites, web applications, smartphone and tablet applications, email and remote access. A test that covers only the main website leaves the rest of that list as an open gap.

NCA ECC-2:2024 says penetration tests must be conducted periodically and leaves the interval to the entity's approved policy, while SAMA CSF 3.2.4 sets an annual test for customer and internet-facing services. NCA's published Penetration Testing Standard template uses every six months for critical systems. Most Saudi organisations test annually at minimum and again before major releases.

The National Cybersecurity Authority has required every entity providing cybersecurity services in Saudi Arabia to register on its platform since 1 August 2022. A Saudi buyer should therefore confirm that the firm performing the penetration test, or its delivery partner, appears on NCA's list of registered service providers.

A vulnerability scan is not enough on its own. NCA ECC treats vulnerability management (2-10) and penetration testing (2-11) as separate subdomains, and SAMA CSF 3.2.4 asks specifically for penetration tests of customer and internet-facing services. A scan supports 2-10; a manual penetration test is what closes 2-11 and 3.2.4.

Personal data discovery under the Saudi Personal Data Protection Law (PDPL) is the process of finding every place an organisation stores or processes personal data, classifying it, including sensitive data, and recording who uses it, why and where it goes. The output feeds the records of processing that Article 31 of the PDPL requires controllers to keep.

The Saudi PDPL does not use the term data inventory, but Article 31 requires controllers to keep a written record of processing activities covering purposes, categories of personal data and data subjects, recipients, retention periods and transfers outside the Kingdom. A controller cannot complete that record accurately without first finding where personal data is held.

Sensitive data under the Saudi PDPL includes data revealing racial or ethnic origin, religious, intellectual or political belief, criminal convictions and offences, biometric or genetic data used for identification, health data, and data indicating that one or both parents are unknown. Sensitive data needs explicit consent and can trigger impact assessments and SDAIA registration.

Pseudonymised data is still treated as personal data under the Saudi PDPL, according to SDAIA guidance summarised by OneTrust DataGuidance, because the key that links it back to individuals still exists. Anonymised data falls outside the PDPL, but the act of anonymising it is itself processing.

A PDPL data map should be updated whenever systems, vendors, purposes or transfers change, and reviewed in full at least once a year. Records of processing must be kept for as long as processing continues and for five years after it ends, so superseded versions should be retained rather than overwritten.

Social engineering, which includes phishing, was used in 30% of successful cyber attacks on Saudi organisations between Q2 2025 and Q1 2026, according to Positive Technologies. IBM's 2026 Cost of a Data Breach findings for Saudi Arabia put the average cost of a phishing-led breach, including voice and SMS phishing, at SAR 30.6 million.

Attackers use generative AI to write fluent, personalised phishing emails and messages, and deepfake video and voice to build trust before a request. Positive Technologies documented AI-generated phishing delivered by email and WhatsApp in the Middle East in June 2025, and IBM found that 25% of malicious breaches in Saudi Arabia in its 2026 study were AI-enabled.

WhatsApp phishing is a social engineering attack sent through WhatsApp, often impersonating a senior executive, a bank or a government service to push an urgent payment or a malicious link. WhatsApp is widely used for business in the Gulf, and the Saudi Central Bank (SAMA) has barred banks from using instant messaging apps such as WhatsApp to communicate with customers, citing security concerns, as reported by Asharq Al-Awsat in March 2025.

The NCA Essential Cybersecurity Controls (ECC-2:2024) require a cybersecurity awareness programme that covers secure handling of email, especially phishing emails (control 1-10-3), and email filtering for phishing plus SPF, DKIM and DMARC (control 2-4-3). ECC does not name phishing simulations, but a simulation is the clearest evidence that the awareness programme works.

A Saudi organisation should run a phishing simulation with written approval, agreed rules of engagement and a lawful basis for processing staff results under the Personal Data Protection Law (PDPL). The campaign should mix email, SMS and voice lures in Arabic and English, measure reporting speed as well as click rates, and feed results back into training and mail-filter tuning.

PHP2Shell is the name used for two critical memory-safety vulnerabilities in the PHP engine, CVE-2026-109618 and CVE-2026-109619, disclosed on 21 October 2026. Both are rated CVSS v4.0 9.2 and can let an unauthenticated attacker run code on a web server with the privileges of the PHP worker.

Every PHP 8.2, 8.3, 8.4 and 8.5 release before 8.2.35, 8.3.36, 8.4.27 and 8.5.12, plus older end-of-life branches. Researchers report the underlying bugs reach back as far as PHP 5.4. PHP 7.4, 8.0 and 8.1 get only minimal source backports, and PHP 7.3 and older get no fix.

Probably, if it runs on an unpatched PHP version. The flaws are in the PHP runtime, not in the CMS or framework, so updating WordPress, Drupal, Joomla or Laravel does not fix them. You or your host must update PHP itself and restart the PHP workers.

Exploitation attempts began on the day of disclosure. Cloudflare reported attack traffic and payloads changing to evade its rules, and watchTowr reported exploitation attempts against both CVEs on 21 October. As of 22 October neither CVE was in CISA's Known Exploited Vulnerabilities catalog, and no confirmed breach of a specific server had been published.

Only partly. PHP says no configuration change fully mitigates these vulnerabilities. Disabling session.upload_progress, turning off fatal_error_backtraces on PHP 8.5, tightening request limits and putting a WAF in front reduce exposure while you patch, but the security release is the only complete fix.

Yes. PHP-FPM pools and Apache processes keep the old engine in memory until they restart. After installing the fixed package, restart PHP-FPM or Apache and confirm the running version, not just the installed one.

A third PHP remote code execution issue added to public advisories on 23 October 2026. PHP has withheld details until its next release and says it only affects unusually configured applications. Setting session.upload_progress.enabled=0 and restarting workers is the advised interim step.

The software side of penetration testing as a service: a portal where test cycles are requested, verified findings are published with evidence and fix guidance, issues are synced to Jira or GitHub, retests are requested and tracked, and reports are downloaded.

Live publication of verified findings, severity and CVSS scores, request and response evidence, specific fix guidance, Jira and GitHub integration, per-finding retests with before-and-after evidence, an activity history, and dated reports for each test cycle.

No, it adds to it. The platform is where work happens day to day; the dated, scoped and retested report for each cycle is still what auditors and buyers receive.

Findings nobody verified by hand, a findings list dominated by missing headers and version banners, retests that are not included, and no way to see who tested what and when.

Traditional penetration testing is a one-off project that ends in a PDF report. PTaaS delivers the same expert testing continuously through a platform, testing releases as they ship, publishing verified findings live, syncing them to Jira or GitHub and retesting fixes on request.

It usually costs more than a single test but less than buying several separate tests a year, because scoping, NDAs and reporting are set up once. The price depends on how many applications are in scope and how often you release.

Yes, as long as each cycle produces a dated report with scope, methodology, findings and retest results. SOC 2 and ISO 27001 auditors look for regular independent testing, which PTaaS provides more often than an annual test.

When the system changes rarely, such as an internal network, a stable thick-client application or a one-time pre-launch check, or when a regulator or customer asks for a single point-in-time test.

Naif Arab University for Security Sciences (NAUSS) counted 31 Saudi ransomware victims in 2025, up from 17 in 2024. That placed Saudi Arabia second among Arab countries after the UAE, which had 38. NAUSS counts victims named on ransomware leak sites, so the real number is likely higher.

The NAUSS Ransomware Trends Report in Arab Countries 2025 attributes 5 Saudi incidents to CL0P, 3 to Kill Security and 1 to Qilin. Positive Technologies also names Ralord, Tengu, Everest, RansomEXX, Qilin, KillSec and Cl0p among groups that attacked Saudi organisations between Q2 2025 and Q1 2026.

The NCA Essential Cybersecurity Controls (ECC-2:2024) do not use the word ransomware. Several ECC subdomains still address it directly: 2-9 Backup and Recovery Management, 2-10 Vulnerability Management, 2-11 Penetration Testing, 2-13 Cybersecurity Incident and Threat Management and 3-1 Cybersecurity Resilience in business continuity.

The NAUSS report finds phishing and user execution recurring across the most active groups, with exploitation of public-facing applications and stolen credentials also prominent. Positive Technologies reports malware in 55%, vulnerability exploitation in 40% and social engineering in 30% of attacks on Saudi organisations between Q2 2025 and Q1 2026.

Ransomware readiness is best tested with a combination of internal network penetration testing, an assumed-breach red team exercise, phishing simulations and a timed restore from backups. Each test answers a different question: can attackers get in, can they spread, will staff report the lure, and can the business recover.

The Reserve Bank of India (Information Technology Governance, Risk, Controls and Assurance Practices) Directions, 2023, issued on 7 November 2023 and effective from 1 April 2024. Paragraph 26 sets out the vulnerability assessment and penetration testing requirements.

For critical information systems and systems in the DMZ with a customer interface, vulnerability assessment at least once every six months and penetration testing at least once every 12 months. VA and PT are also expected before and after implementation and after major changes. Non-critical systems follow a risk-based approach.

Commercial banks (including foreign banks, small finance banks and payments banks), NBFCs in the top, upper and middle layers, credit information companies and all-India financial institutions such as EXIM Bank, NABARD, NaBFID, NHB and SIDBI. Local area banks and core investment companies are excluded.

The Master Direction asks for appropriately trained and independent information security experts or auditors rather than naming CERT-In empanelment. Many banks and NBFCs still choose empanelled auditors because boards, internal audit and other regulators recognise them.

Post-implementation penetration testing should be done on production. If testing happens in a test environment instead, it must match production in version and configuration, and any differences must be documented and approved by the Information Security Committee.

Yes. Sumrite runs independent, manual VAPT for banks, NBFCs and fintechs, with reports mapped to paragraph 26, CVSS scoring and a retest, and can route the report through our CERT-In empanelled partner where you need one.

A penetration test looks for as many weaknesses as possible in a defined scope and proves their impact. A red team operation pursues a goal, such as reaching sensitive data, while testing whether your people and tools detect and respond.

Most organisations should run penetration tests first and fix the findings. Red teaming is most useful once you have basic controls and a monitoring capability to test.

Typically weeks, because the aim is stealth and persistence rather than speed.

It can support some programmes, but audits that ask for a penetration test usually want a scoped test report. A red team adds assurance beyond it.

Because that header is added by HTTP.sys, the Windows kernel-mode HTTP listener, not by IIS. HTTP.sys answers some requests itself, such as malformed requests, unknown host names and requests that arrive while an application pool is stopped. Set the DisableServerHeader registry value to 2 and restart the HTTP service to remove it.

No. Microsoft documents that the attribute was added in IIS 10.0 and does not work before Windows Server version 1709 or Windows 10 version 1709. On older versions, blank the header with a URL Rewrite outbound rule or a small managed module.

No. A determined attacker can still fingerprint the server from error pages, header order, cookie names such as ASP.NET_SessionId and file extensions. Removing version headers is still worth doing because it stops automated scanners and casual reconnaissance, and it is a standard VAPT and audit finding.

Restarting the HTTP service stops every service that depends on it, including IIS (W3SVC and WAS), so plan a short maintenance window or reboot the server during one.

Use 2. According to Microsoft, 1 only stops HTTP.sys adding the header to responses it generates itself, while 2 stops HTTP.sys appending a Server header to any response. A header your application or IIS sets explicitly is not removed, which is why you also need removeServerHeader.

SAMA requires annual penetration testing of customer and internet-facing services. SAMA Cyber Security Framework subdomain 3.2.4 states that customer and internet facing services should be subject to annual review and penetration tests, with results recorded, reported to the business owner and followed up until issues are addressed.

The twice-a-year penetration testing rule comes from SAMA's Cyber Resilience Fundamental Requirements (CRFR), control 3.2.6, which says entities should conduct penetration testing twice a year as a minimum or after a major or critical change. The CRFR applies to entities entering SAMA's Regulatory Sandbox or applying for a licence, not to every licensed bank.

The SAMA Cyber Security Framework lists penetration testing, where applicable, as part of change testing under subdomain 3.3.7 Change Management. The SAMA CRFR is more explicit and requires a penetration test after any major or critical change in addition to the twice-yearly minimum.

The most common SAMA penetration testing mistakes are testing only the flagship app instead of every customer and internet-facing service, skipping the APIs behind mobile banking, and closing the engagement without a retest. SAMA CSF 3.2.4 requires follow-up reviews to confirm issues were addressed, so a report with no tracked remediation only meets part of the control.

A SAMA red teaming exercise does not replace the annual penetration test. SAMA's Financial Entities Ethical Red Teaming Framework states that red teaming is not a penetration test, and SAMA CSF 3.2.4 still requires annual review and penetration tests of customer and internet-facing services.

The SAMA Cyber Security Framework is the Saudi Central Bank's mandatory set of cyber security controls for the financial institutions it regulates. SAMA issued the framework under Circular 381000091275 dated 24 May 2017, and the SAMA Rulebook lists it as in force. The framework is organised into four domains and is assessed against a six-level maturity model.

The SAMA Cyber Security Framework applies to all SAMA Member Organizations: banks, insurance and reinsurance companies, financing companies and credit bureaus operating in Saudi Arabia, and the financial market infrastructure. All domains apply to banks, while a few subdomains are excluded or conditional for non-bank institutions.

Section 2.4 of the SAMA Cyber Security Framework states that Member Organizations should at least operate at maturity level 3 or higher. Maturity level 3, named Structured and formalized, means cyber security controls are defined, approved and implemented, and compliance with the cyber security documentation is monitored.

The four domains of the SAMA Cyber Security Framework are Cyber Security Leadership and Governance (3.1), Cyber Security Risk Management and Compliance (3.2), Cyber Security Operations and Technology (3.3) and Third Party Cyber Security (3.4). Each domain is split into numbered subdomains with a principle, an objective and control considerations.

The SAMA Cyber Security Framework requires penetration testing under subdomain 3.2.4, which states that customer and internet facing services should be subject to annual review and penetration tests. Subdomain 3.3.7 on change management also lists penetration testing, where applicable, as part of testing changes.

The SAMA FEER framework is the Saudi Central Bank's Financial Entities Ethical Red Teaming Framework, issued under Circular 562240000067 dated 13 May 2019. FEER guides SAMA Member Organizations in preparing and executing controlled, threat-intelligence-based red teaming tests against their live production environment with certified and experienced Red Teaming Providers.

The SAMA Financial Entities Ethical Red Teaming Framework states that each regulated Member Organization should be tested at least once every three years. SAMA also has the authority to select any Member Organization and request a red teaming test, and Member Organizations may run tests on their own initiative.

A SAMA red teaming exercise is not a penetration test. The FEER framework explains that a penetration test assesses one or more specific information assets, while red teaming replicates a targeted and realistic attack against the entire Member Organization to test detection and response.

The four phases of a SAMA FEER red teaming exercise are the Preparation Phase, the Scenario Phase, the Execution Phase and the Lessons Learned Phase. FEER describes the Lessons Learned Phase as lasting approximately four weeks and including a debrief, a red and blue team replay exercise and a remediation plan.

A FEER red teaming test does not replace SAMA's annual penetration test. SAMA Cyber Security Framework subdomain 3.2.4 still requires annual review and penetration tests of customer and internet-facing services, so financial entities need both.

A cover page with scope and test dates, an executive summary with an overall risk rating and a count of findings by severity, a methodology section, each finding with evidence, impact and remediation steps, a remediation tracker, and a retest section showing which findings are now closed.

Sumrite publishes a sample VAPT report at sumrite.com/resources/sample-vapt-report, including a short video walkthrough. A redacted full-length sample is sent on request.

It is the one page leadership, procurement and auditors read. It gives the overall risk in plain language, the number of critical, high, medium and low findings, and what has to be fixed before the report is shared with a customer or auditor.

Each finding gets a severity of critical, high, medium or low, usually based on a CVSS score adjusted for real business impact: what data or function an attacker reaches and how hard the attack is to carry out.

A good one does. After your team fixes the findings, the tester verifies each fix and the final report or retest letter marks findings as closed. Auditors and enterprise buyers usually ask for this evidence.

The Saudi Arabia cybersecurity market was worth SAR 16.3 billion in 2025, according to the National Cybersecurity Authority (NCA) report on Key Economic Indicators in the Cybersecurity Sector, published on 14 October 2026. The NCA defines the market as total spending on cybersecurity products and services by public and private entities.

The Saudi cybersecurity market grew at a compound annual growth rate of 10.7% between 2023 and 2025, according to the National Cybersecurity Authority (NCA). The NCA's previous report put the 2024 market at SAR 15.2 billion, against SAR 16.3 billion for 2025.

The private sector spends the most on cybersecurity in Saudi Arabia, at SAR 11.2 billion or 69% of the market in 2025, according to the National Cybersecurity Authority (NCA). Government spending was approximately SAR 5.1 billion, or 31%.

More than 22,000 cybersecurity professionals worked in Saudi Arabia in 2025, according to the National Cybersecurity Authority (NCA), with the workforce growing at about 5.9% a year between 2023 and 2025. Women made up 33% of the Saudi cybersecurity workforce, against a global average of about 22% cited by the NCA.

The Saudi cybersecurity sector contributed approximately SAR 20 billion to GDP in 2025 at current prices, according to the National Cybersecurity Authority (NCA). That equals 0.42% of total GDP and 0.71% of non-oil activity, split between SAR 9.7 billion direct and SAR 10.3 billion indirect contribution.

The Saudi Personal Data Protection Law (PDPL) is Saudi Arabia's general data protection law, issued by Royal Decree No. M/19 and amended by Royal Decree No. M/148. The PDPL came into force on 14 September 2023 and became fully enforceable on 14 September 2024 after a one-year grace period. The Saudi Data & AI Authority (SDAIA) supervises and enforces it.

Yes. Article 2 of the Saudi PDPL covers processing inside the Kingdom and processing by parties outside the Kingdom of personal data relating to individuals residing in Saudi Arabia. A foreign SaaS provider, retailer or group company handling Saudi residents' data is therefore in scope.

The Saudi PDPL allows a warning or a fine of up to SAR 5 million per violation under Article 36, and the fine can be doubled for repeat violations. Disclosing or publishing sensitive data with intent to harm or for personal benefit can bring up to two years' imprisonment and a fine of up to SAR 3 million under Article 35.

The Saudi PDPL does not name penetration testing. The PDPL requires controllers to apply appropriate organisational, administrative and technical measures to protect personal data, and SDAIA has penalised controllers for failing to do so. Regular penetration testing of systems that hold personal data is the clearest evidence that those technical measures work.

Under SDAIA's Rules Governing the National Register of Controllers Within the Kingdom, registration is required for public entities, controllers whose main activity is based on processing personal data, controllers that process sensitive data, and individuals processing personal data beyond personal or family use. Controllers outside these criteria are not currently required to register, but should document why.

Controllers register on SDAIA's National Data Governance Platform at dgp.sdaia.gov.sa. The platform has separate registration routes for government entities, private organisations, non-profit entities and entities outside the Kingdom, and it also hosts compliance assessment, privacy impact assessment and breach notification services.

An SDAIA registration certificate on the National Register of Controllers is valid for up to five years. SDAIA notifies the controller at least 30 days before expiry so that it can apply for renewal, and the public can verify a controller's registration.

The Personal Data Protection Law (PDPL) applies to processing of personal data of people in Saudi Arabia even by parties outside the Kingdom, and the National Data Governance Platform lists a registration route for entities outside the Kingdom. SDAIA's October 2026 draft amendments would also make registration mandatory for any controller that transfers or discloses personal data outside the Kingdom.

No. As of November 2026 the wider registration criteria are draft amendments to the PDPL Implementing Regulation that SDAIA put out for public consultation until 5 November 2026. As drafted, they would take effect 60 days after publication in the Official Gazette, once approved.

The Cybersecurity and Cyber Resilience Framework for SEBI Regulated Entities, issued by circular SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113 on 20 August 2024. It replaced SEBI's earlier, separate cybersecurity circulars with one framework that scales requirements by the size and type of the regulated entity.

It depends on the category. Market infrastructure institutions and Qualified Stock Brokers follow a half-yearly VAPT cycle, while most other regulated entities run VAPT at least once a year. Testing is also expected after major changes to critical systems.

Yes. VAPT under CSCRF has to be carried out by a CERT-In empanelled information security auditing organisation, and depositories have asked for the revalidation of fixes to be done through a CERT-In empanelled auditor as well.

Vulnerabilities should be closed within three months of the VAPT report. Anything still open after that needs approval from the entity's IT Committee with a justification, and must be closed before the next VAPT cycle. SEBI's FAQs expect high-severity issues caused by missing patches to be fixed within a week.

CSCRF has five categories: MIIs, Qualified REs, Mid-size REs, Small-size REs and Self-certification REs. The category is fixed at the start of each financial year based on the previous year's data, such as client numbers, trading volume or assets. Entities with several SEBI registrations follow the requirements of their highest category.

Yes. Sumrite runs the full engagement, from scoping and manual testing to the revalidation, and routes the formal report through our CERT-In empanelled partner, so you deal with one team.

Strict never sends the cookie on requests that start from another site, including when a user clicks a link to you from an email or search result. Lax also blocks cross-site requests, except top-level navigations with safe methods such as GET, so following a link still sends the cookie and the user arrives logged in.

Lax is the right default for most session cookies: it blocks cookies on cross-site form posts, fetch and XHR, and keeps users logged in when they arrive from a link. Use Strict for high-risk applications such as banking and admin consoles, often by adding a second Strict cookie for sensitive actions. Use None only when the cookie must work inside another site.

Chromium-based browsers such as Chrome and Edge treat it as Lax, with a short exception that allows top-level POST requests within two minutes of the cookie being set. Other browsers behave differently, so always set SameSite explicitly rather than relying on defaults.

No. SameSite=Lax or Strict blocks most cross-site request forgery, but it does not protect against attacks from sibling subdomains, which count as the same site, or against state-changing GET requests under Lax. Keep CSRF tokens or equivalent framework protection for state-changing requests.

Browsers reject SameSite=None cookies that are not marked Secure. Cookies that are sent across sites must at least travel only over HTTPS so they cannot be read or changed on the network.

It stops scripts reading the cookie value, which blocks the simplest theft. It does not stop injected script from making requests in the user's session, because the browser still attaches the cookie. Fixing the XSS itself and adding a Content Security Policy are still needed.

A foreign SaaS vendor selling to Saudi Arabia usually meets Saudi requirements through its customers' contracts rather than directly. Government and critical national infrastructure buyers flow down the NCA Essential Cybersecurity Controls (ECC-2:2024) third-party controls in ECC 4-1 and, for cloud services, the NCA Cloud Cybersecurity Controls (CCC-2:2024), while the Personal Data Protection Law (PDPL) applies whenever the vendor processes personal data of people in the Kingdom.

NCA ECC 4-1 requires the Saudi entity to define cybersecurity requirements for third-party contracts, including non-disclosure and secure data removal at the end of the service, incident communication procedures, and an obligation for the supplier to follow the entity's cybersecurity policies and applicable laws. For outsourced IT, cybersecurity and managed services, ECC 4-1-3 adds a pre-contract risk assessment and requires remote-access monitoring and operations centres to be located fully inside Saudi Arabia.

NCA CCC-2:2024 applies to a SaaS company when it provides cloud services to in-scope tenants, meaning Saudi government entities and private organisations that own, operate or host critical national infrastructure. In that case the SaaS company is a cloud service provider under CCC, with 37 main controls and 94 subcontrols, including penetration tests of the cloud technology stack at least once every six months.

The Saudi PDPL applies to processing of personal data of individuals residing in the Kingdom, including processing by parties outside Saudi Arabia, according to SDAIA's guide for controllers and processors. A foreign SaaS vendor usually acts as a processor, so its Saudi customer must ensure it complies, and transfers outside the Kingdom must follow SDAIA's transfer rules, such as its Standard Contractual Clauses.

Saudi buyers typically expect a recent manual penetration test of the SaaS application and its APIs, a summary or report showing scope, methodology and findings by severity, and retest evidence that critical and high findings are closed. Buyers covered by NCA ECC must test periodically under ECC 2-11, and CCC requires cloud service providers serving in-scope tenants to test the cloud technology stack at least every six months.

The Trust Services Criteria do not name penetration testing as a mandatory control. In practice most auditors and nearly every enterprise customer reviewing a SOC 2 report expect independent penetration testing as evidence for monitoring and vulnerability management controls, so most SaaS companies treat it as required.

An executive summary, the scope with dates and exclusions, the testing methodology, each finding with severity, evidence and remediation advice, a summary of risk, and a retest section or letter showing which findings were fixed and verified. Mapping findings to the relevant Trust Services Criteria makes the auditor's job easier.

SOC 2 does not set a frequency. Most organisations test at least once a year, and again after significant changes to the application, infrastructure or identity setup. For a Type 2 report, the test should fall inside or close to the observation period.

Usually not. Automated scans are good evidence for ongoing vulnerability management, but auditors and customers generally expect an expert-led penetration test that covers business logic and access control, which scanners cannot assess.

The auditor needs enough to judge whether your controls work: the scope, the findings, how you rated and treated them, and evidence that serious ones were fixed. Open findings are not automatically a problem if they are tracked with an owner and a remediation plan.

Red teaming is a goal-based simulation of a real attacker. A small team of specialists tries to reach agreed objectives, such as access to customer data or a payment system, using any realistic technique within agreed rules, including phishing, exploiting systems and moving through the network. It tests your detection and response, not just your vulnerabilities.

A penetration test tries to find as many vulnerabilities as possible in a defined scope, usually with the security team aware. A red team engagement pursues specific objectives across people, process and technology, often without most defenders knowing, to see whether an attack would be detected and stopped.

Typically four to twelve weeks, depending on objectives, scope and whether it includes phishing, physical or assumed-breach phases. Planning and reporting add time before and after the active phase.

Red teaming is most valuable once you have basic security controls, regular VAPT and a team or provider that monitors and responds to alerts. If you have never had a penetration test, start there; a red team will mostly confirm gaps a VAPT would find faster and more cheaply.

Some regulated sectors, particularly financial services, increasingly expect adversary simulation or red team exercises as part of cyber resilience. Requirements vary by regulator and entity category, so check the current circulars that apply to you.

There is no single best provider for everyone. The right choice depends on what you need tested, whether a regulator requires a CERT-In empanelled auditor, your budget, and how much expert-led testing and support you need. Compare providers on sample reports, tester experience, methodology and whether retesting is included.

Only when a regulator, government body or contract requires it, for example some audits for government entities and regulated financial institutions. Many private companies need VAPT for SOC 2, ISO 27001 or customer due diligence, where CERT-In empanelment is not required. Check your specific requirement and CERT-In's current empanelled list. If you do need a formal CERT-In audit, Sumrite runs the engagement and routes the audit through our empanelled partner, so you still deal with one team.

Prices depend on scope: the number of applications, APIs, mobile apps and hosts, testing depth and whether a retest is included. Ask several providers to quote against the same written scope, and ask how much of the effort is expert-led testing rather than automated scanning.

A single web application or API typically needs three to ten working days of testing, plus reporting and a retest after fixes. Larger scopes such as internal networks or multiple applications take longer.

An executive summary, scope and dates, methodology, each finding with severity, evidence and specific remediation, a findings summary and a retest section. If you need it for compliance, ask for a mapping to the relevant framework, such as SOC 2, ISO 27001 or RBI guidelines.

By the tester's level of knowledge, penetration tests are black box (no credentials or internal information), grey box (test accounts and some documentation) and white box (full access to source code, architecture and configuration). Tests are also grouped by target, such as web application, API, mobile, network, cloud, thick client, social engineering and red team testing.

In black box testing the tester starts with nothing but the target's address, like an outside attacker, so the test shows what is exposed to the internet but spends time on discovery. In white box testing the tester has source code, architecture and configuration, so they can trace weaknesses directly and cover far more of the system in the same time.

For most applications, grey box testing gives the best value: the tester gets accounts for each user role, so they can test access control and business logic, which is where the most serious issues usually are. Add white box elements such as code review for high-risk systems, and use black box testing when the question is specifically what an anonymous outsider can reach.

Mostly. Authenticated testing means the tester logs in with valid accounts, which is the defining feature of a grey box web, API or mobile test. Grey box can also include partial documentation such as API specifications or network diagrams.

None of them mandates black, grey or white box by name. PCI DSS requires internal and external penetration testing at least every 12 months and after significant changes. SOC 2 auditors and ISO 27001 certification bodies look for a risk-based, independent test with a clear scope, and in practice expect authenticated testing of the applications in scope.

No. White box access makes a penetration test more thorough, but source code review alone cannot show how the deployed system, its configuration and its infrastructure behave together. The strongest approach combines code review with live testing of the running application.

The UAE Personal Data Protection Law is Federal Decree-Law No. 45 of 2021, the country's first federal data protection law. It took effect in January 2022 and sets rules for processing personal data, individuals' rights, security, breach notification and cross-border transfers.

No. The financial free zones with their own data protection laws are outside the federal PDPL. DIFC has its Data Protection Law and ADGM has its Data Protection Regulations, each with its own regulator.

Yes, in some cases. It covers controllers and processors inside the UAE and those outside the UAE that process personal data of people in the UAE.

The UAE Data Office, established under a separate federal decree-law, is the federal data protection regulator. It issues guidance and handles complaints and breach notifications.

The law excludes, among others, government data and government entities, personal data held by security and judicial authorities, health and banking or credit data that have their own legislation, and free-zone companies subject to their own data protection laws.

Very low prices usually mean a scanner export with a logo on it. Compare what each quote includes: authenticated testing, verification, evidence, remediation advice and a retest.

It should be. Sumrite includes a retest of fixed findings, so you can show that issues are closed.

Yes. Fix scanner-level issues first using a free scan, give a clear scope, prepare test accounts and avoid scope changes during the test.

Before the first enterprise deal, not during it. Procurement reviews move much faster when you can attach a recent penetration test report and a retest, rather than promising one after signature.

The customer-facing web application and its API, tested with real roles and at least two tenants. Add a cloud configuration review once you run production on AWS, Azure or GCP.

Not always, but many enterprise buyers ask for SOC 2 or an equivalent. A recent third-party penetration test is often the minimum evidence they accept while SOC 2 is in progress.

At least annually, and after major releases, new payment flows or cloud migrations. Keep each report and retest for your audit evidence.

A Saudi buyer should choose a penetration testing company whose testing entity is registered with the National Cybersecurity Authority (NCA), that scopes from the asset inventory, tests manually, maps findings to NCA ECC 2-11 or SAMA CSF 3.2.4, and includes a retest. Asking for a sample report and named testers before signing separates real testing firms from scan resellers.

The National Cybersecurity Authority states that registration on its digital platform has been a regulatory requirement for entities providing cybersecurity services in Saudi Arabia since 1 August 2022. NCA publishes a list of registered service providers, so a buyer can check the registered entity name of the firm, or delivery partner, that performs the test.

Ask a Saudi penetration testing vendor which entity is NCA-registered, who the named testers are, how much of the effort is manual, how findings map to ECC 2-11 and SAMA CSF 3.2.4, how test data is stored and destroyed, and whether a retest is included. Ask for a redacted sample report to judge quality.

Most 'Top 10 penetration testing companies in Saudi Arabia' lists are published by vendors that rank themselves first. A buyer gets a more reliable shortlist by applying the same written checklist to every vendor, checking NCA registration, and comparing redacted sample reports side by side.

A penetration test of a single web application in Saudi Arabia usually takes one to two weeks of testing plus reporting, and multi-asset scopes take longer. Buyers should also allow time for remediation and a retest, because NCA and SAMA reviewers look for evidence that findings were closed.

Generally no. DIFC and ADGM have their own data protection regimes. Check which regime covers your entity and activity before choosing how to map the report.

Named assets, methodology, verified findings with severity, evidence, remediation and a retest, written so a procurement or regulatory reviewer can map them to their controls.

A scoped web application or API assessment is delivered in 48 hours, including the report. Broader cloud, network or mobile scopes take longer.

Yes. Sumrite delivers VAPT reports for UAE teams, mapped to DIFC, ADGM, CBUAE and UAE PDPL expectations, with an NDA before any technical discussion.

A vulnerability assessment is a largely automated scan that lists known weaknesses across many systems and rates them by severity. A penetration test is an expert-led simulated attack that tries to exploit weaknesses, including business-logic and access-control flaws scanners cannot see, and proves what an attacker could actually achieve.

NCA ECC-2:2024 requires both, as separate subdomains. ECC 2-10 (Vulnerabilities Management) requires periodic vulnerability assessment and detection, severity classification and risk-based remediation, while ECC 2-11 (Penetration Testing) requires periodic penetration tests of all internet-facing services. Evidence for one control does not satisfy the other.

No. A vulnerability scan supports ECC 2-10 but does not satisfy ECC 2-11, which requires penetration tests that simulate real attack methods against internet-facing services such as websites, web applications, mobile apps, email and remote access. An NCA assessor expects separate evidence for each control.

VAPT stands for vulnerability assessment and penetration testing. VAPT combines automated vulnerability assessment for breadth with manual penetration testing for depth, which is why a VAPT engagement maps naturally to both NCA ECC 2-10 and ECC 2-11.

NCA ECC-2:2024 says both must run periodically without fixing an interval. NCA's Vulnerabilities Management Standard template suggests at least annual assessment, monthly for internet-facing critical systems and quarterly for internal critical systems, while its Penetration Testing Standard template suggests critical systems are tested every 6 months.

Web application security is subdomain 2-15 of the NCA Essential Cybersecurity Controls (ECC-2:2024). ECC 2-15 requires entities to define, implement and periodically review protection requirements for external web applications, with minimums that include a web application firewall, a multi-tier architecture, secure protocols such as HTTPS, a secure usage policy and risk-based user authentication. Penetration testing of those applications sits separately under ECC 2-11.

Yes. ECC 2-11-3-1 in ECC-2:2024 puts all internet-facing services and their technical components in penetration testing scope, and websites and web applications are named explicitly. ECC 2-11-3-2 requires those tests to run periodically, and the entity sets and justifies the interval in its approved penetration testing policy.

ECC-2:2024 says penetration tests must be conducted periodically without fixing an interval, so most Saudi entities test every internet-facing web application at least annually and before major releases. Banks, insurers and other SAMA-regulated firms face a firmer rule: SAMA Cyber Security Framework section 3.2.4 says customer and internet facing services should be subject to annual review and penetration tests.

A web application penetration test in Saudi Arabia should follow the OWASP Web Security Testing Guide for test cases, report findings against the OWASP Top 10:2025 categories, and add the OWASP API Security Top 10 for the APIs behind the application. Testing should be manual and authenticated across every user role, because broken access control and business-logic flaws are invisible to scanners.

No. A web application firewall is only one of five minimum requirements in ECC 2-15-3, alongside a multi-tier architecture, secure protocols, a secure usage policy and suitable user authentication. A WAF also does not fix flaws in the application itself, so ECC 2-11 penetration testing is still needed to prove the application resists real attacks.

Web application VAPT (vulnerability assessment and penetration testing) is a security test of a web application in which testers first identify weaknesses and then try to exploit them, the way a real attacker would. For a SaaS product it covers the login and session handling, user roles and tenant separation, business workflows, APIs behind the front end, and the configuration the application runs on.

At least once a year, and after any significant change such as a new major feature, a change to authentication, a new integration or an infrastructure migration. Fast-moving SaaS teams increasingly test before major releases or on a quarterly cycle, with a retest after each round of fixes.

No. OWASP is an open community that publishes free security guidance, such as the OWASP Top 10, the Web Security Testing Guide and the Application Security Verification Standard. A VAPT that follows OWASP shows your application was tested against widely recognised criteria, but OWASP does not certify applications.

It depends on the size of the application and the number of roles. Sumrite delivers the report for a standard web application or API within 48 hours of testing; larger platforms take longer. Retesting of fixed findings is included.

A written scope and authorisation, the URLs or environments in scope, test accounts for every user role (two tenants for multi-tenant SaaS), API documentation if available, and a technical contact. Staging is often used, provided it matches production.

Yes. Ask to see a redacted sample report, ask how much of the testing is done by experts, check that retesting is included, confirm the report maps to the framework your customers or auditors use, and score providers on the same criteria. The scorecard in this guide is designed for exactly that.

A VAPT comprises scoping and an NDA, a vulnerability assessment that maps the attack surface and known weaknesses, manual penetration testing that tries to exploit them, risk rating of each finding, a report with evidence and fixes, remediation support, and a retest that confirms the fixes work.

The vulnerability assessment finds and lists possible weaknesses, largely with tools. The penetration test is the manual part, where an expert tries to exploit them, chains them together and proves what an attacker could actually reach.

An executive summary, a detailed technical report with each finding's severity, evidence and remediation, a remediation tracker, and a retest report or letter showing which findings are closed. Sumrite also maps findings to the compliance frameworks you are working towards.

Web applications, APIs, mobile apps, internal and external networks, cloud accounts, thick-client applications and source code. Each needs its own approach, so the scope lists every asset, environment and user role to be tested.

It should be. Without a retest you only know what was wrong, not that it is fixed. Sumrite includes a retest of fixed findings in standard engagements.

The Digital Personal Data Protection Act, 2023 is India's law on how organisations collect, use, store and protect digital personal data. It gives individuals rights over their data and requires organisations to obtain valid consent or rely on a permitted legitimate use, protect the data with reasonable security safeguards and report breaches.

The DPDP Rules, 2025 were notified on 13 November 2025 and set a phased start. Provisions establishing the Data Protection Board took effect immediately, consent manager rules after 12 months, and most substantive obligations, including notice, consent, security, breach reporting and data principal rights, after 18 months, in May 2027.

It applies to processing of digital personal data within India, and to processing outside India if it is connected to offering goods or services to people in India. Companies of every size are covered, with some exemptions, for example for certain government functions, research and personal or domestic purposes.

The Schedule to the Act sets penalties per instance of up to ₹250 crore for failing to take reasonable security safeguards, up to ₹200 crore each for failing to notify a breach and for breaching obligations relating to children, up to ₹150 crore for breaching obligations of significant data fiduciaries, and up to ₹50 crore for other breaches.

The data fiduciary must inform affected individuals and the Data Protection Board without delay after becoming aware of a personal data breach, and must give the Board a detailed report, including causes, impact and measures taken, within 72 hours unless the Board allows longer.

The Act does not name penetration testing. It requires reasonable security safeguards to prevent breaches, and the Rules list measures such as encryption, access control, logging and monitoring. Regular security testing is the most direct way to show those safeguards work.

PTaaS, or penetration testing as a service, is expert-led penetration testing delivered continuously through a platform rather than as a one-off project. Testers check new releases as they ship, verified findings appear live with evidence and fix guidance, they can be sent to Jira or GitHub, and fixes are retested on request.

No. A real PTaaS service is led by human testers. Automation covers the routine baseline, but every finding is tested by hand and verified before it is published, and the focus is the access-control, business-logic and chained issues scanners miss.

It can. A PTaaS programme includes full application tests on a regular cycle plus release-based testing in between, and you can export a dated report for any cycle for SOC 2, ISO 27001 or a customer questionnaire.

Each test cycle and its scope, every verified finding with severity, CVSS score, evidence and fix guidance, its status from open to fixed and verified, the activity history, and the final reports for auditors and buyers.

VAPT stands for Vulnerability Assessment and Penetration Testing. Vulnerability assessment finds and lists weaknesses across your systems; penetration testing attempts to exploit them to show which ones are real and how much damage they could cause.

It depends on scope. A single web application or API typically takes three to ten working days of testing, a network a few days to several weeks, and a combined assessment longer. Reporting and retesting add time after testing finishes.

At least once a year for internet-facing and critical systems, after significant changes such as a major release or cloud migration, and whenever a customer, auditor or regulator requires it. Vulnerability scanning should run more often, monthly or continuously.

No. A report contains the scope, findings, evidence and fixes. A certificate or attestation letter is a short summary that the testing was done and findings were addressed, often shared with customers. Auditors usually want the report or at least the executive summary and retest results.

Yes. Sumrite has helped more than 100 companies across the Gulf region with penetration testing, delivered remotely from New Delhi. Reports are mapped to what DIFC, ADGM, CBUAE and the UAE PDPL reviews ask for, with a retest of fixed findings included.

Yes. Sumrite tests web applications, APIs, mobile apps and cloud environments for companies serving Saudi customers, with reports organised around NCA ECC, SAMA and Saudi PDPL expectations. Engagements are delivered remotely and include a retest.

A scanner report is an automated list of possible issues, usually header and configuration findings, with generic advice. A VAPT report is written by an expert who has confirmed each finding is exploitable, shown the impact with evidence and given fixes specific to your system.

Because they are what automated scanners find first and fastest. Missing CSP, HSTS, Server header disclosure and anti-clickjacking headers are real but low-impact hygiene issues. A report made mostly of them usually means the testing stopped at the scanner.

Yes. Sumrite's free scan at scan.sumrite.com finds the scanner-level issues such as CSP, HSTS, Server header and clickjacking. You pay for the expert work that finds what a scanner cannot, such as broken access control and business-logic flaws.

A scope and methodology section, an executive summary, each finding with severity, evidence and reproduction steps, specific remediation advice, and a retest section showing which findings are now closed.

Many reviewers reject it. SOC 2 and ISO 27001 auditors and procurement teams usually want evidence of an independent penetration test with verified findings and a retest, not an unreviewed tool export.

PCI DSS names penetration testing directly in requirement 11.4. Several regional regimes, such as NCA ECC in Saudi Arabia and DORA's threat-led testing for some financial entities, also name testing or assessment.

The DPDP Act requires reasonable security safeguards. Regular expert-led testing is a practical way to show them.