The Core Definition

A penetration test — often called a pentest or ethical hack — is a controlled, authorized simulation of a cyberattack. A team of certified security engineers uses the same tools, techniques, and tactics that real-world attackers use to probe your network, applications, or personnel for exploitable weaknesses. The goal is simple: find the vulnerabilities before an attacker does, understand how they could be exploited, and provide a clear roadmap for fixing them.

What Makes It Different From a Security Audit?

A security audit reviews policies, procedures, and configurations against a standard or framework. A penetration test is active — engineers actually attempt to exploit discovered weaknesses. Auditing your locks is different from hiring a locksmith to try to pick them. Both have value, but only one tells you whether your locks actually hold.

What Does a Pentest Actually Involve?

A professional penetration test follows a structured testing methodology. At Grid32, that process includes: Reconnaissance, Scanning and Enumeration, Vulnerability Mapping, Exploitation and Privilege Escalation, and Reporting with a full remediation roadmap.

Types of Penetration Tests

• External network penetration testing — attacking from the internet
• Internal network penetration testing — simulating an insider or post-breach attacker
• Wireless penetration testing — assessing Wi-Fi infrastructure
• Web application penetration testing — attacking web apps, APIs, and portals
• Social engineering and phishing — testing your human layer

How Is a Pentest Different From a Vulnerability Assessment?

A vulnerability assessment scans your environment and produces a list of potential issues. A penetration test goes further — it attempts to exploit those issues to determine whether they represent genuine, actionable risk.

The Quick Answer

A vulnerability assessment identifies potential security weaknesses and catalogues them. A penetration test attempts to exploit those weaknesses to prove they represent genuine risk. Both are valuable — but they answer different questions.

What Is a Vulnerability Assessment?

A VA uses automated scanning tools and manual review to identify known vulnerabilities across your environment — unpatched software, misconfigured services, weak cipher suites, and similar issues. VAs are typically faster and less expensive than penetration tests. They work best as a regular hygiene exercise — run quarterly or monthly to catch newly-disclosed vulnerabilities and configuration drift.

What Is a Penetration Test?

A penetration test takes VA output and goes further. Our engineers actively attempt to exploit discovered vulnerabilities, chain multiple weaknesses together, escalate privileges, and move laterally through the environment — exactly as a real attacker would. The result is a demonstrated narrative of what an attacker could actually accomplish.

Key Differences

• Depth — A VA identifies issues; a pentest proves they're exploitable
• Methodology — VAs rely heavily on automated tools; pentests are primarily manual
• Output — VA produces an issue list; pentest produces an attack narrative with evidence
• Compliance value — Many frameworks (PCI DSS, SOC 2, CMMC) specifically require penetration testing

Which Should You Choose?

For organizations at an early stage of security maturity, a vulnerability assessment is a good first step. For organizations past the basics, or that face compliance requirements, a penetration test provides the depth a VA cannot. Many organizations run both: regular VAs as an ongoing hygiene measure, with penetration tests annually for deeper validation.

The Short Answer

Most penetration test engagements — from initial scoping to final report delivery — take between two and four weeks. The active testing phase itself typically runs one to two weeks, depending on scope.

Factors That Affect Timeline

• Scope size — Number of IP addresses, hosts, or applications in scope is the primary driver
• Test type — External tests are often faster than internal tests
• Environment complexity — Complex segmentation or large application codebases require more time
• Combined engagements — Combined network and web app or social engineering testing extends the timeline

Typical Timeline Breakdown

1. Scoping and SOW (1–3 days) — After you submit your quote, Grid32 reviews and issues a Statement of Work
2. Pre-test coordination (2–5 days) — Confirming scope, authorizations, and technical prerequisites
3. Active testing (5–10 business days) — Our engineers conduct the engagement
4. Report writing and QA (3–5 business days) — All findings documented, severity-rated, and reviewed
5. Report delivery and debrief — Full report package delivered with walkthrough available

Rush Engagements

If you have a compliance deadline or other time-sensitive requirement, contact us to discuss expedited scheduling.

Why Pricing Varies So Much

Penetration testing pricing varies enormously across the industry — from a few thousand dollars to well over $100,000 — because "penetration test" covers a wide range of scope, methodology, and quality. A report produced by automated scanning tools is fundamentally different from one produced by a senior certified engineer conducting manual testing. Both may be sold as "penetration tests."

What Drives the Cost?

• Scope size — Number of external IPs, internal hosts, or web applications in scope
• Test type — Internal tests typically cost more than external; combined engagements more than single-scope
• Methodology — Manual testing by senior engineers costs more than automated scanning — and is substantially more valuable
• Report depth — Tiered reporting with executive summaries and attestation documentation takes more time to produce

Grid32 Pricing

Grid32 offers transparent, scope-based pricing through our online quote builder. You define your scope; we provide a clear price. No discovery calls required. No surprise line items after the SOW.

You Get What You Pay For

The cheapest penetration test is often not a penetration test at all — it's an automated vulnerability scan with a branded PDF wrapper. See our full discussion on pentest pricing →

Why Scope Matters

Network penetration testing isn't one-size-fits-all. A well-scoped engagement targets the areas of your environment that are most exposed, most critical, or most relevant to your compliance requirements.

External Network Penetration Testing

External pentesting simulates an attacker on the internet targeting your perimeter — public IP addresses, web servers, VPN concentrators, mail gateways, DNS infrastructure, and firewall rules. External testing is the recommended starting point for organizations new to pentesting, addressing the most immediately exposed attack surface. Learn more →

Internal Network Penetration Testing

Internal pentesting simulates a threat that has already bypassed the perimeter — an insider, compromised remote worker, or attacker who gained initial access via phishing. Internal tests frequently uncover the most severe findings, because internal networks are often significantly less hardened than external-facing systems. Learn more →

Wireless Network Penetration Testing

Wireless testing assesses encryption standards, network segmentation, rogue access point detection, and authentication controls. Many organizations are surprised to find that their wireless network provides an easy path into their internal environment. Learn more →

Combining Scopes

A combined external and internal engagement reflects the reality of how most breaches unfold: an initial perimeter breach followed by lateral movement. Grid32 offers flexible scoping — build your custom quote online or contact us to discuss what combination makes sense.

What Is External Penetration Testing?

External penetration testing simulates the perspective of an attacker on the open internet — someone with no prior access who is probing your external attack surface for a way in. Our engineers conduct this test entirely from outside your network, targeting every internet-exposed asset associated with your organization.

What External Testing Covers

• All public IP addresses and associated services
• Web servers, web applications, and public portals
• VPN and remote access infrastructure
• Email and mail transfer infrastructure
• DNS configuration and zone security
• Firewall and edge device exposure
• SSL/TLS configuration and certificate validity
• OSINT — what publicly available information could assist an attacker?

Why External Testing Is a Critical Starting Point

Your external attack surface is the front door that every attacker on the internet can knock on. Most organizations that have never had a formal external test have at least one significant finding — often more.

How Often Should You Test Externally?

We recommend annual external testing at minimum, with additional testing after significant infrastructure changes — new services launched, acquisitions, cloud migrations, or changes in your IP space. Many compliance frameworks require annual external testing explicitly.

What Is Internal Penetration Testing?

Internal penetration testing simulates a threat actor who has already gained access to your internal network — whether through a phishing attack, stolen credentials, a compromised remote connection, or a malicious insider. Our engineers connect directly to your internal environment and attempt to enumerate systems, exploit weaknesses, escalate privileges, and access sensitive data.

Why Internal Testing Reveals the Most Severe Findings

Many organizations invest heavily in perimeter security but leave their internal networks comparatively flat and unprotected. Once inside, an attacker often finds few barriers between a standard workstation and highly sensitive assets like domain controllers, file servers, databases, and financial systems. Internal tests regularly uncover misconfigurations, unpatched systems, overly permissive access controls, and lateral movement paths that would allow an attacker to compromise an entire domain from a single initial foothold.

What Internal Testing Covers

• Active Directory enumeration and privilege escalation
• Lateral movement and credential harvesting
• Internal network segmentation assessment
• Unpatched or misconfigured internal services
• Access to sensitive data, shares, and databases
• Detection and response testing — how long before your team notices?

Why Wireless Security Deserves Its Own Assessment

Wireless networks introduce a unique threat model: an attacker doesn't need to be inside your building to attack. Anyone within radio range — in your parking lot, your lobby, or the building next door — can attempt to access your wireless network. Yet wireless is frequently the least-scrutinized part of most organizations' network security.

What Wireless Penetration Testing Covers

• Encryption and authentication — Are you using WPA2 or WPA3 Enterprise? Any legacy WEP or WPA Personal devices?
• Network segmentation — Is your guest network truly isolated from your corporate network?
• Rogue access point detection — Are there unauthorized access points connecting to your network?
• Evil twin attacks — Can an attacker create a spoofed network that devices connect to automatically?
• Credential attacks — Can wireless authentication credentials be captured and cracked?

Combining Wireless With Network Testing

Wireless testing is most valuable when combined with an internal network penetration test. Once an attacker gains wireless access, the next step is lateral movement — testing both together provides a complete picture of the risk.

Phase 1: Scoping and Quoting

Every engagement begins with scoping — defining exactly what systems, applications, and users are in scope. Grid32 offers an online quote builder that lets you define your scope and receive a price without a sales call. We review and issue a Statement of Work typically within one business day.

Phase 2: Pre-Test Coordination

After the SOW is executed, we schedule the engagement and exchange technical prerequisites. For internal tests: VPN or on-site access. For web app tests: test account credentials. We confirm rules of engagement — what's in scope, emergency contacts, and any systems requiring special handling.

Phase 3: Reconnaissance

Our engineers gather information about the target using both passive techniques (OSINT, DNS, certificate transparency logs) and active techniques (network scanning, service enumeration). The goal: develop a comprehensive map of the attack surface before exploitation begins.

Phase 4: Scanning and Enumeration

We systematically probe all in-scope systems to identify running services, versions, and configurations — producing a detailed inventory and initial identification of exploitable weaknesses.

Phase 5: Exploitation and Privilege Escalation

Our engineers attempt to exploit discovered vulnerabilities, chain issues together, escalate privileges, and move laterally through the environment. Every successful exploitation is documented with evidence. We never cause damage or data loss — the goal is proof of impact.

Phase 6: Reporting

All findings are compiled into a comprehensive report — every vulnerability ranked by severity with evidence, business impact assessment, and specific remediation guidance. Reports are reviewed internally before delivery.

Phase 7: Debrief and Remediation Support

We walk through findings with your team, answer questions, and help prioritize your response. Many clients return for a follow-up assessment after remediation to verify that issues have been resolved.

Why Report Quality Matters

A penetration test is only as valuable as the report that comes out of it. A list of CVE numbers and CVSS scores is not a roadmap for improvement — it's noise. Grid32's reports are designed to be genuinely useful to every audience that needs to act on them.

Executive Summary

Written for C-suite leaders and board members who need to understand business implications without technical detail. It includes an overall risk assessment, the most significant findings in plain language, and a high-level remediation priority summary. Many clients use this section directly in board presentations or risk committee reports.

Detailed Technical Report

Designed for CISOs, IT directors, compliance officers, and security leadership. It provides a full inventory of all findings, organized by severity, with: detailed vulnerability descriptions, step-by-step evidence of exploitation, severity ratings and CVSS scores, business impact assessment, specific actionable remediation guidance, and prioritization recommendations.

Attestation and Client-Facing Reports

For organizations that need to demonstrate their security posture to customers, auditors, or regulators, Grid32 provides attestation reports and client-summary documents. Learn more about attestation reports →

Remediation Verification

After you've addressed findings, we offer follow-up verification testing to confirm that vulnerabilities have been remediated effectively — particularly valuable before audit cycles.

The Short Answer

Yes — when performed by experienced professionals using manual methodologies, penetration testing is safe. Grid32 has conducted over a thousand engagements across networks, web applications, and social engineering scenarios without a single unintended service disruption. Our safety record is not an accident — it's the result of deliberate methodology.

Why Automated Tools Create Risk

The primary risk in penetration testing comes from automated scanning tools that send high volumes of requests to services that may not handle them gracefully. Grid32's methodology is manual-first. Our engineers understand the potential impact of each technique before applying it, and avoid anything that could cause service disruption in a production environment.

Testing Windows and Scheduling

For organizations with business continuity concerns, we can schedule intensive testing phases during off-hours, weekends, or maintenance windows. We work around your operational requirements.

Emergency Stop Protocols

Every engagement includes a designated point of contact at your organization who can halt testing immediately if needed. Established before testing begins as part of our standard rules of engagement.

What We Never Do

• Delete, modify, or exfiltrate production data
• Deploy persistent malware on in-scope systems
• Use exploits known to cause system crashes in production environments
• Continue testing if unexpected system instability is observed

It Depends on What You're Trying to Measure

Whether to notify your IT team and employees before a penetration test depends on your objectives. There are good reasons to go either way, and the right answer often involves partial disclosure — telling some people but not others.

The Case for Notifying IT Staff

Notifying your IT team allows them to: be prepared to assist if needed, avoid unnecessarily responding to testing activity as a real incident, and handle automated blocking systems (IPS, EDR, SIEM alerts) appropriately. Most network penetration tests involve notifying at least a small group of IT leadership who serve as points of contact.

The Case for Blind Testing

If one of your objectives is to test your incident detection and response capabilities — how quickly your team notices an attacker, and how effectively they respond — then notifying IT defeats the purpose. Blind or "red team" engagements specifically withhold information from IT staff to assess real detection capability.

Social Engineering: The Notification Decision Matters Most

For social engineering assessments, the decision is particularly consequential. Notifying employees before a phishing campaign eliminates its value entirely. Most clients choose not to notify staff prior to social engineering testing — but do notify HR and select leadership so they can manage any employee concerns that arise.

Our Recommendation

For most network penetration tests: notify a small group of IT leadership but not the broader team. For social engineering: don't notify staff, but notify HR and select leadership. We'll discuss the right approach for your specific engagement before testing begins.

A Common Misconception

Some IT leaders are apprehensive about penetration testing because they worry about what it might imply about their team's performance. The honest answer: almost every penetration test finds significant issues, in almost every organization, regardless of how capable the IT team is. This is not a reflection on the team — it's a reflection on the inherent complexity of securing modern IT environments under real operational constraints.

Security vs. Functionality: An Inherent Tension

IT teams are under constant pressure to make systems accessible, easy to use, and functional. Those objectives are often in direct tension with security hardening. An independent security assessment isn't a verdict on IT — it's a tool that gives IT the specific, evidence-based findings they need to make the case for remediation investment and get proper attention from leadership.

The CFO / CPA Analogy

Just as a CFO relies on an independent CPA firm to audit financials — not because the CFO is doing anything wrong, but because independence adds credibility — IT and security leaders benefit from an independent penetration test that validates their environment and surfaces issues with an outside perspective that internal teams cannot replicate.

How We Work With Your Team

Throughout every engagement, we maintain open communication with your designated contacts. Our reports include specific, actionable remediation guidance written for technical teams — not vague recommendations that leave engineers guessing.

The Baseline: Annual Testing

For most organizations, annual penetration testing is the recommended minimum. A year is long enough for meaningful changes to accumulate — new services, configuration drift, new attack techniques, newly-disclosed vulnerabilities — that a fresh test will find new issues even if last year's findings have been fully remediated.

When to Test More Frequently

• Compliance requirements — PCI DSS requires annual external testing and testing after significant changes. CMMC and financial regulations may require similar frequency.
• High-risk industries — Financial services, healthcare, legal, and government contractors often justify semi-annual or quarterly testing cycles.
• Rapid environment change — If your infrastructure or application stack changes significantly, test again after those changes — don't wait for the annual cycle.
• Following a security incident — After a breach or near-miss, testing should occur as part of the remediation and validation process.
• Mergers and acquisitions — Before integrating an acquired organization's network, test it independently.
• Cyber insurance requirements — Some insurers now require periodic penetration testing as a policy condition.

Building a Testing Program

The most mature security programs treat penetration testing as an ongoing program rather than a one-time event. Grid32 offers multi-engagement and recurring testing packages for organizations building structured programs. Contact us to discuss program options →

What Data Grid32 Accesses

During a penetration test, our engineers may access data as a natural consequence of testing — for example, demonstrating that a vulnerability allows access to a database or file share. We document findings as proof of exploitability but do not copy, retain, or transmit client data beyond what is necessary to demonstrate the finding.

Confidentiality and Data Handling

All Grid32 engagements are subject to mutual non-disclosure agreements. Testing notes, screenshots, and evidence are retained only for the duration of the engagement and report production, then securely destroyed. Deliverables are transmitted via encrypted channels.

Background-Checked, U.S.-Based Staff Only

Every Grid32 engineer undergoes a thorough background check before joining our team. All staff are U.S.-based direct employees — no offshore contractors, subcontractors, or third parties. Your data never leaves a controlled environment staffed by vetted professionals.

We Never Share Your Information

Grid32 does not share, sell, or disclose any client information — including the fact that you're a client — to any third party. Contact information is never used for marketing or solicitations.

Specialists, Not Generalists

Many cybersecurity firms offer penetration testing as one service among dozens. For these firms, pentesting is a line item. For Grid32, it's everything. Our entire team, methodology, and culture is built around one discipline: finding the vulnerabilities in your environment that an attacker would exploit.

Fifteen-Plus Years of Focused Experience

Grid32 was founded in New York City in 2009. We've conducted over a thousand engagements across financial services, healthcare, legal, technology, government contracting, and many other sectors. That depth of experience means our engineers have seen — and exploited — virtually every attack pattern in production environments.

Manual-First Methodology

We use tools to assist our engineers — not to replace them. This means we find vulnerabilities that scanners miss, and we understand the full business impact of every finding we deliver.

Elite, Certified, U.S.-Based Team

Our engineers hold CISSP, GPEN, GXPN, OSCP, OSCE, CDPSE, CCIE, and other advanced certifications. All are U.S.-based direct employees — no offshore contractors, no subcontractors. Every engineer has been background-checked and is a full-time Grid32 team member.

Zero Service Disruptions

One thousand-plus engagements. Zero unintended service disruptions. That record is a direct result of our manual methodology and our engineers' discipline in understanding the potential impact of every technique before applying it.

A Policy We Never Compromise On

Every Grid32 engineer is a U.S.-based direct employee. We do not use offshore contractors, subcontractors, staffing agencies, or any third-party delivery model. Every person who accesses your network, tests your applications, or contacts your staff during a social engineering engagement is a full-time Grid32 team member who has passed a comprehensive background check.

Why This Matters for Security

Penetration testing requires privileged access to your most sensitive systems. During an internal network test, our engineers have domain-level access equivalent to a privileged insider. The integrity of everyone who touches your engagement is not a secondary concern — it is the foundation of the entire trust relationship.

Compliance Implications

For organizations subject to ITAR, CMMC, FedRAMP, or other government contracting requirements, the use of offshore personnel in security testing may create compliance violations. For financial institutions, healthcare organizations, and legal firms handling highly confidential data, the chain of custody over that data during a test matters.

Background Checks and Vetting

Every Grid32 engineer undergoes a thorough background check as a condition of employment. Many of our engineers come from backgrounds in government, defense, and critical infrastructure where security clearances are standard.

Grid32 Finds the Issues — Your Team Fixes Them

Grid32's role is to identify vulnerabilities, demonstrate their exploitability, explain their business impact, and provide specific guidance on how to remediate them. Implementing those fixes is the responsibility of your IT and development teams — or your managed service provider if you use one.

How Our Reports Make Remediation Easier

Grid32's remediation guidance is written to be actionable, not abstract. For each finding, we provide: the specific vulnerability and its root cause, recommended remediation steps with specific configuration changes or patch versions where applicable, priority level so your team knows what to fix first, and references to vendor advisories and industry standards.

Post-Remediation Verification

Many clients engage Grid32 for a follow-up verification assessment after remediation is complete — particularly before an audit cycle, a compliance deadline, or before sharing an attestation report with customers. This confirms that findings have been properly addressed and provides documented evidence of remediation.

What If We Don't Have the Internal Resources?

If your organization lacks the internal technical resources to remediate findings, we can recommend trusted managed service providers or refer you to specialists in specific areas. We're invested in your security outcomes beyond the delivery of the report.

The Short Answer: Yes, With Proper Coordination

Grid32 can test infrastructure hosted or located outside the United States. External penetration testing of internet-facing assets is inherently geography-agnostic — we test your IP addresses and domains regardless of where the underlying servers are physically located.

Considerations for International Testing

• Legal authorization — You must have full legal authority to authorize testing of all in-scope systems. Written authorization from appropriate parties is required before testing begins.
• Data residency and privacy laws — GDPR and other jurisdictions have specific requirements that may be relevant to how testing evidence is handled.
• Network accessibility — Internal testing of geographically distributed networks may require coordination around VPN access or remote connectivity.
• On-site testing — Physical social engineering assessments at international locations require separate coordination and are scoped separately.

If you have international infrastructure to include in your engagement scope, contact us before building your quote. We'll work through the requirements together.

Penetration Testing Price Ranges Vary Enormously

It's not uncommon for organizations to receive proposals ranging from $2,000 to $50,000+ for what appears to be the same service. Understanding what drives that variance is essential to evaluating proposals intelligently.

Why Some Pentests Are Very Inexpensive

• Automated scanning, not manual testing — Automated tools can run against your environment in hours. The report is generated by software, not written by an engineer. This is a vulnerability scan with a branded PDF wrapper — not a penetration test.
• Offshore delivery — Significantly less expensive, but introduces supply chain risk, accountability gaps, and potential compliance issues.
• Junior or uncertified staff — Experienced, certified penetration testers are expensive to employ. Some firms substitute junior analysts with limited offensive security experience.
• Shallow scope — A low price may reflect a very narrow scope that misses significant portions of your environment.

Why Some Pentests Are Very Expensive

Premium pricing is not always justified. Some large consulting firms charge significant premiums reflecting brand name and overhead rather than testing quality. A Big Four firm is not necessarily providing better penetration testing than a specialized boutique — in many cases, the inverse is true.

How to Evaluate a Proposal

• Ask specifically: is this manual testing or primarily automated scanning?
• Ask about the certifications held by the engineers who will actually perform the test
• Ask whether any work is subcontracted or performed offshore
• Ask to see a sample report — report quality is indicative of test quality
• Ask about experience in your specific industry and with your technology stack

What Is an Attestation Report?

An attestation report confirms that an independent security assessment was conducted, summarizes the scope and methodology, and attests to the overall security posture of the tested environment — typically without disclosing specific vulnerabilities discovered. It provides proof that you have taken proactive steps to validate your security without exposing sensitive findings to external parties.

Who Uses Attestation Reports?

• Customers and clients — Enterprise customers increasingly require vendors to demonstrate independent security assessments. An attestation report satisfies this without sharing your internal findings.
• Auditors — SOC 2, HIPAA, and other frameworks require evidence of security testing. Grid32's reports are structured to satisfy these requirements directly.
• Cyber insurers — Many carriers require or provide premium discounts for organizations with documented penetration testing.
• Regulators — Financial regulators (FINRA, FFIEC) and government contractors (CMMC) may require documented evidence of security assessments.
• Board and senior leadership — A board-level attestation summary provides governance evidence that security testing is occurring regularly.

What Grid32 Provides

In addition to standard deliverables (executive summary, technical report, findings inventory), Grid32 can prepare customized attestation letters and client-summary documents tailored to your specific use case — whether you need to satisfy a customer questionnaire, regulatory submission, or audit requirement.

Insurance Pays for Breaches — Testing Prevents Them

Cyber insurance and penetration testing are not alternatives — they're complements. Insurance provides financial recovery after a breach occurs. Penetration testing reduces the likelihood and severity of a breach occurring in the first place. One addresses consequence; the other addresses probability.

Cyber Insurers Are Increasingly Requiring Pentesting

The cyber insurance market has hardened significantly in recent years, driven by substantial losses from ransomware and data breach claims. In response, insurers have raised premiums, tightened coverage terms, and increasingly require applicants to demonstrate security hygiene — including documented penetration testing — as a condition of coverage or to qualify for better rates.

What Insurance Won't Cover

• Reputational damage that your policy doesn't quantify
• Regulatory fines and penalties in many jurisdictions
• Loss of customer trust and contracts following a disclosed breach
• Operational disruption of incident response, regardless of insurance payout

Policy Exclusions

Many cyber insurance policies include exclusions for breaches where the organization failed to maintain reasonable security practices. A history of penetration testing and documented remediation is evidence of reasonable security practice — which matters if you ever need to make a claim.

Internal Assessment Has Inherent Blind Spots

IT administrators and internal security teams are excellent at what they do — but they're assessing the same systems they built, configured, and maintain. That proximity creates blind spots. They know what they intended to build; they don't always see the gap between that intention and what was actually deployed. An outside team with no prior knowledge of your environment and an adversarial mindset will find things that internal teams consistently miss.

What Organizations Typically Find on Their First Test

In our experience over fifteen years and thousands of engagements, organizations that have never had a formal penetration test — regardless of how confident they feel — have significant findings. Common discoveries include:

• Legacy systems or services running that IT wasn't aware of
• Default or weak credentials on network devices, servers, or applications
• Overly permissive internal access controls that allow lateral movement to sensitive assets
• Unpatched systems in areas considered "low priority" that provide escalation paths
• Web application vulnerabilities not discovered in development or QA
• Wireless networks not properly segmented from the corporate environment

The CFO Analogy

No finance leader would tell their board "we don't need an external audit because our CFO says the numbers are right." The value of an independent audit is precisely its independence. Security is no different.

Give Your Admin the Backup They Need

An independent penetration test doesn't undermine your IT admin — it supports them. It provides evidence-based findings that make the case for remediation investment, and it gives leadership the independent validation they need to trust that your security posture is what it appears to be.

Web Applications Are a Primary Attack Target

Web applications are internet-facing, handle sensitive user data, and are built under constant development pressure — making security an easy afterthought. They're among the most commonly exploited assets in data breaches. Web application penetration testing is the most effective method available for identifying security flaws before attackers do.

What Is Web App Pentesting?

Web application penetration testing is a manual security assessment of your web application, its APIs, and the underlying infrastructure. Our engineers assess the application from multiple angles: as an unauthenticated external attacker, as a standard logged-in user, and as a privileged user — attempting at each level to access data and functionality they shouldn't be able to reach.

What We Look For

• Injection vulnerabilities (SQL, command, LDAP, XPath)
• Broken authentication and session management
• Sensitive data exposure and insecure transmission
• Insecure direct object references and broken access controls
• Security misconfigurations and verbose error messages
• Cross-site scripting (XSS) and cross-site request forgery (CSRF)
• Business logic vulnerabilities unique to your application
• API authentication and authorization flaws

Why Automated Scanners Aren't Sufficient

Automated scanners are fast and inexpensive, but they miss the vulnerabilities that matter most: business logic flaws, authentication bypasses, and complex attack chains. A scanner finds a known SQL injection pattern; a skilled engineer finds the combination of three individually-minor issues that together allow account takeover. Grid32's methodology is manual-first.

Unauthenticated (External) Testing

Unauthenticated testing simulates an anonymous attacker with no login credentials — attempting to exploit vulnerabilities visible from the public-facing application. This reveals information disclosure, injection vulnerabilities, authentication bypass opportunities, and any content or functionality that should require authentication but doesn't.

Authenticated (Credentialed) Testing

Authenticated testing provides our engineers with standard user credentials and assesses what a logged-in user can access or manipulate beyond their intended permissions. This is where broken access control, insecure direct object references, privilege escalation, and horizontal privilege issues (accessing other users' data) are discovered. Many clients are surprised to learn that the most severe vulnerabilities in their application are in the authenticated portions — areas that external scanners never reach.

API Security Testing

Modern applications expose much of their functionality through APIs. These endpoints are frequently less scrutinized than the visible front-end, and often contain the same — or worse — vulnerabilities. API penetration testing specifically addresses authentication, authorization, rate limiting, input validation, and data exposure across your API layer.

Infrastructure and Hosting Review

Beyond the application code itself, we assess the security of the hosting environment — cloud configuration, server hardening, TLS configuration, dependency vulnerabilities, and deployment practices. Application-layer findings are often compounded by infrastructure weaknesses that amplify their impact.

What Is OWASP?

The Open Web Application Security Project (OWASP) is a nonprofit foundation that produces freely available research, tools, and standards for improving web application security. It's maintained by a global community of security researchers and practitioners and is widely recognized as the authoritative source on web application security best practices.

The OWASP Top 10

The OWASP Top 10 is a regularly-updated list of the most critical web application security risks — based on frequency of occurrence, severity, and detectability. The current Top 10 includes categories such as Broken Access Control, Cryptographic Failures, Injection, Security Misconfigurations, and Server-Side Request Forgery (SSRF), among others. Any serious web application penetration test should systematically address every category in the OWASP Top 10.

How Grid32 Uses OWASP

Grid32's web application testing methodology is built around the OWASP Testing Guide — the most comprehensive resource for web application security assessment. We use it as the structural backbone of every web app engagement, ensuring systematic coverage of all major vulnerability classes while leaving room for creative, application-specific testing that uncovers business logic flaws and novel attack paths.

Beyond the Top 10

The OWASP Top 10 captures the most common risks — but real applications have unique attack surfaces. Our engineers go beyond the checklist, developing application-specific attack scenarios based on your technology stack, functionality, and business context. The combination of systematic coverage and adversarial creativity is what distinguishes a thorough pentest from a scan.

Why APIs Are a Growing Attack Target

Modern applications are heavily API-driven. Mobile apps, single-page applications, third-party integrations, and microservices architectures all rely on APIs to function. This means that an application's business logic — and its most sensitive data — is increasingly accessible through API endpoints that may receive far less security scrutiny than the visible front-end.

What API Penetration Testing Covers

• Authentication and authorization — Can an unauthenticated user call API endpoints? Can an authenticated user access resources belonging to other users?
• Broken object level authorization (BOLA/IDOR) — The most common and impactful API vulnerability: changing an ID in a request to access another user's data
• Excessive data exposure — Do API responses return more data than the client interface displays?
• Rate limiting and resource exhaustion — Can the API be abused to enumerate users, brute-force credentials, or cause denial of service?
• Mass assignment — Can API parameters be manipulated to write to fields that should be read-only?
• Injection in API parameters — SQL, command, and other injection vulnerabilities via API request bodies and query strings

REST, GraphQL, and SOAP

Grid32 tests all common API architectures: RESTful APIs, GraphQL endpoints (including introspection abuse and query depth attacks), and legacy SOAP-based web services. Each architecture has a distinct attack surface, and our engineers are experienced with all of them.

Email Phishing: Still the Most Effective Attack Vector

Despite decades of security awareness campaigns, email phishing remains the single most successful method attackers use to gain initial access to organizations. A convincing email — especially a targeted spear-phishing message — is extremely difficult to distinguish from legitimate correspondence, even for trained security professionals.

How Our Email Phishing Assessments Work

Grid32's email phishing campaigns use a staged approach. We begin with broad, low-sophistication messages — the kind your email filters should catch — and progressively increase sophistication, advancing to:

• Targeted spear-phishing using publicly available information about your organization
• Business email compromise scenarios impersonating executives or finance personnel
• Mimicked domains that closely resemble your organization's actual domains
• Credential harvesting pages that capture login attempts
• Malicious attachment simulations that assess whether users open files from unknown senders

This staged approach reveals not just whether your users will fall victim, but at what level of sophistication — which is exactly the information you need to calibrate your defenses.

What We Measure

Our email phishing report tracks open rates, click rates, credential submission rates, and attachment interaction rates across all campaign stages. Results are provided at both aggregate and individual level (where authorized), enabling targeted follow-up training for the most susceptible users.

Combining With Security Awareness Training

The results of a real phishing assessment are the most powerful input for security awareness training. Employees who fell for a simulated attack are far more receptive to learning — the experience makes the risk real in a way that generic training videos never can.

What Is Vishing?

Vishing — voice phishing — is the use of telephone calls to manipulate individuals into revealing sensitive information, performing actions, or granting access they shouldn't. Attackers impersonate IT support, executives, HR personnel, vendors, or regulators to create urgency and authority that overrides users' normal judgment.

Why Vishing Works

Phone calls activate a different psychological response than emails. The real-time, conversational nature creates pressure that email does not. Caller ID spoofing makes it trivial to appear to be calling from inside your organization. And most employees have never received vishing awareness training — they're trained to spot phishing emails, not manipulative phone calls.

How Grid32's Vishing Assessments Work

Our engineers use a range of pre-designed social engineering scenarios — adapted to your organization's structure and industry — and vary techniques based on results as the engagement progresses. Common scenarios include:

• IT help desk impersonation requesting credentials for "account verification"
• Executive or leadership impersonation requesting urgent wire transfers or information
• Vendor or supplier impersonation attempting to update payment details
• HR or payroll impersonation requesting personal employee information

Both live human calls and automated scenarios are used, as attackers use both and each produces different results. All calls are designed to be non-disruptive — typically under a minute per contact.

The Rise of SMS-Based Attacks

SMS phishing — or smishing — is one of the fastest-growing attack vectors in the social engineering landscape. Key factors make it particularly effective: most users are far less suspicious of text messages than emails, SMS bypasses corporate email filters entirely, text messages have significantly higher open and click rates than email, and two-factor authentication codes sent via SMS are a high-value target.

Common Smishing Scenarios

• Fake IT notifications requesting credential confirmation via a spoofed login page
• HR or payroll impersonation requesting personal information updates
• Package delivery notifications with malicious links
• Executive impersonation requesting urgent responses or information
• Two-factor authentication code harvesting via social engineering

How Grid32's Smishing Assessments Work

For smishing assessments, it's best to provide Grid32 with a list of authorized employee phone numbers — ensuring we only contact authorized targets and that message rates are managed appropriately on company-provided devices. Our engineers craft messages tailored to your organization and adapt based on results throughout the campaign.

Results are reported with the same granularity as email phishing — click rates, credential submission rates, and individual-level details where authorized.

The Physical Attack Vector

Physical access to a facility dramatically expands an attacker's capabilities. Once inside, a threat actor can plant hardware keyloggers between keyboards and computers, deploy network implants that create persistent remote access, plug into internal Ethernet ports, access unattended workstations, or photograph sensitive documents — all without touching your digital perimeter. Despite this, physical security is the least-tested element of most organizations' security posture.

How Physical Social Engineering Testing Works

Grid32's on-site social engineering assessments involve our engineers visiting your facility and attempting to gain physical access using deception and social engineering. Methods are adapted to your building layout, access control systems, and security staff. Typical scenarios include:

• Posing as a delivery courier or package service requiring building access
• Impersonating an IT or facilities contractor
• Tailgating through secured doors behind authorized employees
• Social engineering reception or security staff to gain visitor access
• Using exit-side doors during high-traffic periods (lunch, end of day)

What We Attempt to Do With Access

If facility access is gained, we attempt to reach network resources — internal Ethernet ports, unattended workstations, server rooms, or network closets — and document how far we were able to go. We never disrupt operations, damage property, or engage in any action that is not pre-authorized in the engagement scope.

Operational Considerations

All physical assessments are carefully scoped in advance. We work with your operations and security leadership to define clear boundaries, establish an emergency contact protocol, and ensure all testing is properly authorized. Discretion and operational safety are paramount.

A Report Designed for Multiple Audiences

Like our network and web application reports, social engineering deliverables are designed to be useful to multiple audiences — from leadership making risk decisions to HR teams managing employee follow-up to IT teams tuning email filters and security controls.

Campaign Overview and Statistics

For each campaign type conducted (email, phone, SMS, physical), the report includes high-level statistics: number of individuals tested, open rates, click rates, credential submission rates, and call interaction rates. Presented with clear visual charts that make trends and outliers immediately apparent.

Progression and Sophistication Analysis

Because Grid32's campaigns are staged — starting broad and escalating in sophistication — the report shows at what level of attack sophistication your defenses and users begin to fail. This is more actionable than a simple pass/fail rate.

Individual-Level Results

Where authorized by the client, individual-level results are included — identifying which users fell for which campaigns. This enables targeted follow-up training for the highest-risk individuals, which is significantly more effective than organization-wide generic training.

Technical Findings and Recommendations

The report also covers how email filtering systems performed, whether phishing infrastructure was detected, how quickly alerts were generated, and specific configuration recommendations for email security controls. Every report concludes with prioritized recommendations spanning technical controls, policy changes, and training recommendations.

Why Password Blacklisting Matters

Even with strong complexity requirements, users frequently choose passwords that include obvious words — your company name, your city, product names, sports teams, or seasonal patterns like "Summer2024!" These passwords satisfy complexity rules but are trivially guessable through targeted dictionary attacks. In nearly every internal penetration test we conduct, password spraying attacks using organization-specific terms are among the first techniques we apply — and among the most successful.

Microsoft Active Directory Password Protection

AD Password Protection has two components: the globally banned password list (maintained by Microsoft, updated automatically) and a custom banned password list that you control. Both are enforced by DC agents installed on your domain controllers, with an Azure AD Password Protection Proxy service for on-premises environments.

What to Include in Your Custom Banned List

• Your organization's name and common abbreviations
• Your product or service names
• Your city, state, and office location names
• Your domain name and subdomain names
• Seasonal patterns ("Spring", "Summer", "Winter", "Fall")
• Current year and near-future years
• Common industry-specific terms in your sector
• Names of leadership, buildings, or office locations
• Previously breached passwords from your own environment

Implementation Steps (On-Premises AD)

1. In the Azure portal, navigate to Azure Active Directory → Security → Authentication Methods → Password Protection
2. Enable "Custom banned passwords" and enter your organization-specific terms, one per line
3. Set Lockout threshold and duration appropriate for your environment
4. Download and install the Azure AD Password Protection DC Agent on all domain controllers
5. Install the Azure AD Password Protection Proxy service on domain-joined servers (minimum two for redundancy)
6. Register the proxy servers with Azure AD using Register-AzureADPasswordProtectionProxy
7. Register the forest using Register-AzureADPasswordProtectionForest
8. Set the DC agent to Audit mode initially, review event logs, then switch to Enforcement mode

Cloud Account Password Security

Microsoft 365 accounts — email, SharePoint, Teams, OneDrive — are among the highest-value targets in any organization's environment. Compromising a single M365 account through password spraying or credential stuffing can provide access to sensitive emails, files, and communication that enables further attacks. Custom banned password lists are a straightforward and highly effective control.

Azure AD Custom Banned Passwords (Cloud-Only)

1. Sign in to the Azure portal as a Global Administrator
2. Navigate to Azure Active Directory → Security → Authentication Methods → Password Protection
3. Under "Custom banned passwords," toggle to "Yes"
4. In the "Custom banned password list" field, enter your organization-specific terms — one per line, minimum 4 characters, maximum 1,000 entries
5. Save the configuration

The custom list is case-insensitive and applies fuzzy matching — common character substitutions (@ for a, 3 for e, etc.) are automatically blocked.

What to Include in Your Banned List

• Company name and abbreviations
• Product, service, and brand names
• Office locations and city names
• Domain and subdomain names
• Common seasonal and year-based terms
• Names of executives and well-known staff members

Pairing With Multi-Factor Authentication

Custom banned password lists significantly reduce password-based attack risk — but don't eliminate it. MFA remains the single most impactful control for protecting cloud accounts. See our Microsoft 365 security hardening guide for complete MFA configuration recommendations.

Password Policy Has Evolved — Are Your Policies Current?

Password best practices have shifted significantly in recent years. NIST's updated Digital Identity Guidelines (SP 800-63B) and Microsoft's own security recommendations have moved away from several long-held conventions that are now understood to make passwords less secure rather than more.

What NIST Now Recommends

• Minimum length of at least 8 characters — but 12–16 is significantly better; passphrases of 20+ characters are excellent
• Do NOT require regular rotation — Mandatory periodic changes (90-day cycles) cause users to make small, predictable changes and actually reduce security
• DO require changes on evidence of compromise — If a credential appears in a breach dataset or is suspected compromised, require an immediate change
• Screen against known compromised passwords — Check new passwords against breach datasets and your custom banned list
• Allow all printable characters — Don't artificially restrict special characters
• No complexity requirements that reduce entropy — Requiring "at least one uppercase, lowercase, number, and symbol" often results in predictable patterns like "Password1!" that crack immediately

What Pentest Experience Confirms

In internal penetration tests, the most commonly cracked passwords share a pattern: they meet complexity requirements but are variations on predictable patterns. "Company2024!", "Summer23", "[City]P@ss" — these crack immediately in targeted attacks. Length is far more valuable than mandatory complexity.

Multi-Factor Authentication Is Not Optional

No password policy fully compensates for the absence of MFA. Even strong, unique passwords can be captured via phishing or keyloggers. MFA — particularly TOTP authenticator apps or hardware tokens — provides a critical secondary layer that password policy alone cannot.

The Cost of Improvising During an Incident

Organizations that experience a significant security incident without an incident response plan consistently report chaotic, poorly-coordinated responses that extend dwell time, increase damage, complicate forensics, and create additional regulatory exposure. The decisions that need to be made in the first hours of a breach are far harder to make well under pressure without a pre-established framework.

Incident Response Plan

An incident response plan (IRP) documents who does what when a security incident occurs. At minimum, it should address:

• Definition of what constitutes a security incident requiring plan activation
• Incident response team composition and contact information
• Escalation and notification procedures — who gets called, in what order, at what thresholds
• Evidence preservation and forensic chain of custody procedures
• Containment, eradication, and recovery procedures for common incident types (ransomware, data breach, account compromise)
• External communication and public relations procedures
• Regulatory and legal notification obligations — breach notification timelines vary by jurisdiction and industry

Retain a Security Incident Response Firm Before You Need One

Trying to hire a forensic incident response firm in the middle of an active breach is difficult and expensive. Retaining an IR firm in advance gives you a pre-negotiated agreement, a team that already understands your environment, and immediate availability when you need them.

Logging and Detection

You cannot respond to what you cannot see. Before an incident, ensure you have comprehensive logging in place — Windows event logs, firewall logs, DNS logs, authentication logs, and endpoint detection and response (EDR) coverage where possible. Logs should be centralized in a SIEM and retained for a sufficient period (90 days minimum; 12 months for regulated environments).

Backup and Recovery

Ransomware is the most common severe incident type affecting mid-market organizations. Effective, tested, offline backup — following the 3-2-1 rule (three copies, two media types, one offsite/offline) — is the single most important control for recovering from ransomware without paying a ransom. Test your backups regularly; untested backups frequently fail when needed.

Why M365 Security Requires Active Configuration

Microsoft 365's default security configuration prioritizes usability and broad compatibility — not hardened security. Out of the box, M365 environments frequently lack critical protections that are available but not enabled by default. Organizations that rely on default settings are leaving significant attack surface exposed. CISA and NCSC have both published specific M365 security guidance following high-profile attacks against M365 environments.

1. Multi-Factor Authentication

Enable MFA for all accounts — no exceptions. Use Conditional Access policies (available in Azure AD P1 and above) rather than per-user MFA. Disable legacy authentication protocols (IMAP, POP3, SMTP AUTH, Basic Auth) which bypass MFA entirely and represent a critical exposure in most M365 environments.

2. Conditional Access Policies

• Require MFA for all users for all cloud apps
• Block legacy authentication protocols
• Require compliant or hybrid Azure AD joined devices for sensitive workloads
• Block access from countries where you have no legitimate business presence
• Enable sign-in risk and user risk policies through Azure AD Identity Protection (P2)

3. Email Authentication (SPF, DKIM, DMARC)

Configure SPF, DKIM, and DMARC for all sending domains. A DMARC policy of p=reject prevents your domain from being spoofed in phishing campaigns against your customers and partners. Absence of DMARC is a finding in nearly every external assessment we conduct.

4. Anti-Phishing and Anti-Malware Policies

• Enable Microsoft Defender for Office 365 (Plan 1 minimum) for Safe Links and Safe Attachments
• Configure anti-phishing policies with impersonation protection for executive accounts and key domains
• Enable "First contact safety tips" to warn users receiving email from first-time senders
• Set Safe Attachments to Dynamic Delivery to detonate attachments in a sandbox before delivery

5. Privileged Identity and Access Management

• Reduce the number of Global Administrators to the minimum necessary (2–4 maximum)
• Enable Privileged Identity Management (PIM) for just-in-time elevation of administrative roles
• Create emergency access ("break glass") accounts with strong passwords and hardware MFA, documented and monitored
• Review and remove guest accounts that are no longer active
• Audit application permissions — third-party apps with excessive OAuth permissions are a frequent attack vector

6. Audit Logging and Alerting

• Enable Unified Audit Logging and retain logs for a minimum of 90 days
• Configure alerts for suspicious sign-in activity, bulk mail deletion, unusual forwarding rules, and new admin role assignments
• Review mailbox delegation and mail forwarding rules regularly — attackers frequently establish forwarding rules for persistent access after initial compromise