● Talk to a security engineer: +92 323 8295031info@protonyte.com  ·  PCSF batch enrolling now

A cloud security assessment that starts with your weakest permission

Most cloud breaches are not exotic exploits. They are a public bucket, an over-privileged role or a forgotten key. Protonyte audits AWS, Azure and GCP the way an attacker would, maps every finding to the relevant CIS benchmark, and helps you close the gaps - for teams in the United States, the UK, Canada and the Gulf.

CLOUD REVIEW SCOPEaws · azure · gcp

Identity & access (IAM)IN SCOPE
Storage exposureIN SCOPE
Network & security groupsIN SCOPE
Secrets & key managementIN SCOPE
Kubernetes / containersOPTIONAL
CIS benchmark mappingINCLUDED
// the basics

What a cloud security assessment covers

We review your cloud configuration and identity model against attacker behaviour and CIS benchmarks, looking for the paths that turn one leaked credential into full account access.

The review combines read-only configuration analysis with hands-on testing of the paths we find, so you get proof of what is actually reachable rather than a raw list of misconfigurations.

  • 01Identity firstMost cloud compromise is privilege abuse, so we start with IAM.
  • 02Exposure mappingEvery public endpoint, bucket and snapshot we can reach.
  • 03Benchmark mappingFindings tied to CIS and your compliance obligations.
  • 04Fix-ready outputConsole steps and IaC snippets your engineers can apply.
// approach

Three ways to work with us

Pick the depth that matches where you are in your cloud journey.

// Read-only

Configuration review

We analyse your cloud configuration and identity model without touching workloads.

  • No production impact
  • Fastest turnaround
  • Great annual baseline
// Hands-on

Cloud penetration test

We attempt real exploitation of the paths we find, from a low-privilege starting point.

  • Proves real impact
  • Tests detection too
  • Best before an audit
// Ongoing

Continuous posture

Recurring reviews as your environment changes, with tracked remediation.

  • Catches drift over time
  • Monthly or quarterly
  • Ideal for fast-growing teams
// methodology

How the review runs

  1. 1

    Access & inventory

    You grant a read-only audit role. We inventory accounts, regions, services and owners.

    • Read-only role provisioned
    • Multi-account inventory
    • Asset and owner mapping
    • Baseline snapshot taken
  2. 2

    Identity analysis

    We map every role, policy and trust relationship to find privilege escalation paths.

    • Over-privileged roles
    • Stale users and keys
    • Cross-account trust review
    • MFA and root account checks
  3. 3

    Exposure testing

    We look at what is reachable from the internet and what an insider could reach.

    • Public buckets and snapshots
    • Open security groups
    • Exposed management endpoints
    • Secrets in code and metadata
  4. 4

    Validation

    We safely confirm the paths that matter, so you know which findings are theoretical and which are real.

    • Controlled proof of access
    • Impact assessment
    • False positives removed
    • Evidence captured
  5. 5

    Report & hardening plan

    You get a prioritised plan with exact fixes, mapped to CIS and your compliance needs.

    • Prioritised by real risk
    • Console and IaC fix steps
    • CIS benchmark mapping
    • Retest after remediation
// the deliverable

What you receive

Reports your board and your engineers can both use. No 400-page scanner dump.

  • Full inventory of cloud assets and owners
  • Privilege escalation paths, drawn out step by step
  • List of everything publicly reachable, with evidence
  • Fix instructions for console and infrastructure-as-code
  • CIS benchmark and compliance mapping
  • Retest confirming your hardening worked
Request a sample report
PROTONYTE · ASSESSMENT REPORTCONFIDENTIAL
Cloud SecurityExecutive summary · 18 findings
Critical finding with proof of conceptCritical
Privilege escalation pathHigh
Weak configurationMedium
Information disclosureLow
// toolkit

Proven tools, in expert hands

ScoutSuitemulti-cloud
ProwlerAWS
CloudSploitconfig
PacuAWS attack
Trivycontainers
kube-benchKubernetes

Not sure what you need tested?

Tell us about your systems and we will recommend the right assessment, with a clear scope and a fixed price.

// where we work

Penetration testing for US companies, run from Karachi

Testing is remote work by nature. We scope on a call, test under a signed agreement and rules of engagement, and report inside your working hours - our day overlaps with the US morning. What changes from country to country is not the testing. It is the clause your report has to satisfy, and whether we are allowed to do the work at all, which we will tell you before you ask.

United States

Where most of this work is bought, and where most of our enquiries now come from. Three things drive it. SOC 2 Type II: the criteria do not name a penetration test, but it sits in the points of focus under CC4.1 and auditors expect one inside the observation window. PCI DSS v4.0.1: 11.4.3 external and 11.4.2 internal testing at least annually, 11.4.6 every six months for service providers - and the tester does not have to be a QSA. The FTC Safeguards Rule: 16 CFR 314.4(d)(2)(i) requires annual penetration testing of any non-bank financial institution without continuous monitoring.

SOC 2 · PCI DSS · GLBAET -9

New York, and the rest of regulated finance

If you hold a NYDFS licence, 23 NYCRR 500.05(a) is explicit: penetration testing from inside and outside your system boundaries, by a qualified internal or external party, at least annually. The Second Amendment finished phasing in on 1 November 2025. California’s CCPA cybersecurity audit regulations took effect on 1 January 2026 and list penetration testing among the things the auditor assesses.

NYDFS 500 · CCPAET -9

United Kingdom, Canada and Australia

English-speaking, used to buying testing from outside their own borders, and driven by the same two things: ISO 27001 certification and the security questionnaire an enterprise customer sends before signing. We take private-sector work in all three. We do not take UK public sector or critical national infrastructure work, which is gated behind NCSC CHECK.

ISO 27001 · questionnairesGMT · ET · AEST

The Gulf and Pakistan

Where we started, and still a real part of the business. Abu Dhabi healthcare works to ADHICS V2 (yearly). Saudi entities under the NCA’s ECC 2:2024 test periodically, or six-monthly for critical systems. SAMA requires annual testing of customer and internet-facing services. UAE licensed financial institutions came under the Central Bank’s C 1/2026 on 14 September 2026. Our office and our academy are in Karachi.

ADHICS · NCA · SAMA · SBPPKT +5

And the work we turn down

We are a Pakistani company. Some US work is closed to a firm like ours, and you should hear that from us rather than from your own legal team three weeks in.

  • Anything federal. FedRAMP and StateRAMP assessments have to be done by an accredited 3PAO. We are not one and cannot become one.
  • Live patient data. Several US states - Wisconsin, Texas, Florida and others - restrict offshore access to health information by contract or by statute. We test healthcare systems against sanitised or staging data, and we put that in the scope document. If your contract needs the work done on US soil, we are the wrong firm.
  • UK public sector and critical national infrastructure. Gated behind NCSC CHECK.
  • Singapore. Penetration testing is a licensed activity there under the Cybersecurity Act, and we do not hold the licence.

Everything else is paperwork, and we keep it ready rather than assembling it after you ask: a mutual NDA, a W-8BEN-E, the testers’ names and certification numbers, a redacted sample report, and a data-handling note saying what we hold and when it is destroyed.

Not sure which of these applies to you? The compliance and audit page sets out what each framework actually asks for, side by side.

// faq

Common questions

Do you need write access to our cloud?

No. A read-only audit role is enough for the configuration review. Hands-on testing uses a low-privilege account you create for us, with scope agreed in writing first.

Can you test multi-account or multi-cloud setups?

Yes. We regularly review AWS Organizations, Azure tenants with multiple subscriptions, and mixed environments. Scope and pricing scale with the number of accounts.

Will this help with our SOC 2 or ISO audit?

Yes. Findings are mapped to CIS benchmarks and the relevant controls, and the report is written so auditors accept it as evidence of testing.

How often should cloud be reviewed?

Cloud changes faster than on-premise, so quarterly is ideal for active environments, and at minimum annually or after any major architectural change.

Do I need permission from AWS, Azure or Google to be tested?

Each provider publishes its own policy on customer penetration testing, and the details change. We confirm the current rules for your provider and services during scoping, and we do not test anything you cannot authorize in writing.

What is the difference between a configuration review and a cloud penetration test?

A configuration review reads your account the way an auditor would: identity policies, storage permissions, logging, network rules, measured against CIS benchmarks. A cloud penetration test attacks it the way an intruder would, starting from whatever foothold is realistic, and proves what that foothold actually reaches.

Which cloud findings matter most in practice?

Identity, almost always. Over-privileged roles, long-lived access keys and trust relationships that let one compromised function assume another role are what turns a small mistake into a full account compromise - far more often than an exotic exploit.

// start here

Let's protect your business together.

Tell us what you need tested. Our team will reply with a clear scope and quote.

By submitting, you agree to our Terms of Use and Privacy Statement.