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.

Summit 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.

Summit 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 Summit 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. It checks for scanner-level issues 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.

Summit provides fixed-price quotes scoped to your application. Contact us at sumrite.com/contact and receive a quote within 15 minutes. 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. Summit 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 Summit 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.

Summit 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.

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

Yes. Summit 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 Summit'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.

Summit 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.

Summit'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.

Summit’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.

For a scoped web application, Summit 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. Summit 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.

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.

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 in 15 minutes, and most teams are testing within days once scope and authorisation are agreed.

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.

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.

The Act sets a schedule of monetary penalties, up to ₹250 crore for failing to take reasonable security safeguards. The Board decides amounts case by case.

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.

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. Summit 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. Summit 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. Summit 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. Summit does not file the report with a regulator on your behalf.

Testing is run by Summit'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. Summit 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 Summit 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. Summit 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.

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. Summit signs an NDA before seeing data-flow detail. The report does not replace an NDMO registration or a legal privacy assessment.

The working language of the test is English. This page includes an Arabic summary for buyers and search engines. Executive summaries can be discussed in Arabic on request. The technical reproduction steps stay in English so developers can follow them exactly.

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

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.

An information security auditing organisation that CERT-In, India's national Computer Emergency Response Team under MeitY, has evaluated and placed on its published panel. Empanelment covers the organisation's audit experience, methodology, team and practical testing skills. CERT-In maintains the list but does not assign auditors; you choose a firm from it.

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. Summit 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.

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.

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.

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.

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. Summit 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.

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.

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.

The Cloud Cybersecurity Controls (CCC) are issued by Saudi Arabia's National Cybersecurity Authority. They set cybersecurity requirements for cloud service providers and for cloud service tenants, the organisations that use cloud services. The current version is CCC-2:2024.

No. CCC extends and complements ECC with cloud-specific requirements. Organisations in scope still need to meet ECC, including its penetration testing control.

Yes. CCC's defense domain covers vulnerability management and penetration testing of cloud services and workloads, on top of ECC's penetration testing requirements. The scope and depth depend on whether you are a provider or a tenant and on the sensitivity of the data you host.

Both, for different layers. The provider tests and secures the cloud platform and tenant isolation; the tenant tests its own workloads, identities, configurations, applications and data. Your shared responsibility model and contract should state the split.

Major public cloud providers publish testing policies. Many allow customers to test their own resources without prior approval but prohibit denial-of-service testing and attacks on the provider's shared infrastructure. Check the current policy of your provider before testing.

At least once every six months for critical systems (CSCC 2-10-2), covering all technical components and all internal and external services.

At least monthly on the technical components of critical systems (CSCC 2-9-2). Patching is monthly for external or internet-connected systems and every three months for internal ones.

No. CSCC extends ECC. Compliance with ECC is a prerequisite for CSCC compliance.

CSCC 2-2-1-1 prohibits remote access to critical systems from outside the Kingdom, so testing access for critical systems should originate inside Saudi Arabia.

They cover the same topic, penetration testing, under different numbering. CSCC 2-10 builds on ECC 2-11-3 with a wider scope and a six-month minimum frequency.

Not in those words. Control 2-11-3-2 requires penetration tests to be conducted periodically and leaves the cadence to the entity. Annual testing of all internet-facing services, plus testing before major changes, is a defensible baseline. Critical systems under CSCC must be tested at least every six months.

All services exposed to the internet and their technical components: infrastructure, websites, web applications, smartphone and tablet apps, email and remote access.

No. Scanning supports vulnerability management (2-10). Penetration testing (2-11) is a separate control that requires simulated attacks on the in-scope services.

Government agencies and their affiliated companies inside and outside the Kingdom, and private entities that own, operate or host Critical National Infrastructure. Other organisations are encouraged to adopt it as good practice.

An approved penetration testing policy, a test plan, scope reconciled to your asset inventory, test reports, a remediation tracker, retest results, and a record of the periodic review of the process.

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.

On 16 January 2026, the Saudi Press Agency reported that SDAIA's violation review committees had issued 48 decisions confirming violations and enforcing the prescribed penalties on data controllers, covering 2025.

Up to SAR 5 million per violation, which can be doubled for repeat violations. Intentional disclosure of sensitive data can also bring up to two years' imprisonment and/or a fine of up to SAR 3 million.

Within five days of notification, according to the committees' Rules of Procedure as summarised by Clyde & Co.

72 hours from becoming aware of the breach, notified to SDAIA. Affected individuals must be notified without undue delay where harm is likely.

Yes. It applies to processing of personal data relating to individuals in the Kingdom, including by entities located outside it.

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.

Yes, for customer and internet-facing services. SAMA CSF subdomain 3.2.4 says they should be subject to annual review and penetration tests.

From the Cyber Resilience Fundamental Requirements (CRFR), control 3.2.6, which applies to entities entering SAMA's Regulatory Sandbox or seeking a licence.

Yes. The CRFR sets penetration testing at least twice a year, or after a major or critical change.

Section 2.4 of the SAMA CSF states that Member Organizations should at least operate at maturity level 3 or higher, where level 3 means structured and formalized.

Not necessarily. Institutions that own or operate critical national infrastructure may also be in scope for NCA's ECC and CSCC.

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.

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, Summit 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. Summit 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.

It depends on scope. Published Saudi price guides put a simple web application test from around SAR 12,000, typical engagements between SAR 25,000 and SAR 100,000, and enterprise-wide assessments above SAR 300,000. Get a quote against your asset list.

NCA requires any entity providing cybersecurity services, solutions or products in the Kingdom to register on its platform, a requirement in force since 1 August 2022.

Ask for the registered entity name and check it against NCA's published list of registered service providers.

A single web application typically takes one to two weeks of testing plus reporting. Larger multi-asset scopes take longer. Allow time for a retest.

External testing usually can. For critical systems under CSCC, remote access from outside the Kingdom is prohibited, so testing access must come from inside Saudi Arabia.

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. Summit delivers VAPT reports for UAE teams, mapped to DIFC, ADGM, CBUAE and UAE PDPL expectations, with an NDA before any technical discussion.

Usually not for audits or enterprise reviews that ask for an independent penetration test. A scan is useful for continuous hygiene but does not show exploitability or business-logic flaws.

Yes. Summit's free scan at scan.sumrite.com checks for scanner-level issues such as CSP, HSTS, Server header and clickjacking protection.

Scan monthly or continuously. Run expert-led VAPT at least once a year and after major changes.

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. Summit 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.

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.

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.

A vulnerability assessment is broad and largely automated: it finds known weaknesses across many systems quickly. A penetration test is deep and expert-led: a tester tries to exploit weaknesses, chain them together and reach sensitive data, which shows real impact and catches logic flaws scanners miss.

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. Summit 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. Summit 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. Summit'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.

Not by name. Article 32 requires appropriate security and regular testing of its effectiveness, and a penetration test is a common way to evidence that.

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