Beyond Compliance: Proactive Security Auditing Strategies for Modern Professionals

Introduction: Why Compliance Alone Is a Dangerous Illusion

In my 15 years of security consulting, I've seen countless organizations fall into the compliance trap—believing that checking boxes on an audit form equals real security. Based on my experience working with financial institutions, healthcare providers, and tech startups, I can tell you this approach is fundamentally flawed. Compliance standards like PCI-DSS or HIPAA provide a baseline, but they're often years behind emerging threats. I remember a client in 2023 who passed their annual compliance audit with flying colors, only to suffer a ransomware attack three months later that exploited a vulnerability not covered by their compliance framework. The attack cost them $2.3 million in recovery and lost business. This experience taught me that true security requires looking beyond what regulations demand to what threats actually exist. In this article, I'll share the proactive strategies I've developed through trial and error, showing you how to build security that anticipates problems rather than just reacting to them. We'll explore how to transform auditing from a periodic chore into a continuous strategic advantage.

The Compliance Gap: Real-World Consequences

Let me share a specific example from my practice. In early 2024, I worked with a mid-sized e-commerce company that had just completed their SOC 2 Type II certification. They believed they were secure because they met all compliance requirements. However, during our proactive audit, we discovered their payment processing system had an API vulnerability that allowed attackers to bypass authentication through a timing attack. This vulnerability wasn't covered by SOC 2 requirements but could have exposed 50,000 customer records. We found it by simulating advanced attack patterns rather than checking compliance items. The fix took two weeks of development work, but it prevented what could have been a catastrophic data breach. According to IBM's 2025 Cost of a Data Breach Report, the average breach cost has risen to $4.45 million, with compliance-focused organizations experiencing 23% higher costs due to slower detection times. My experience confirms this: reactive security based solely on compliance leaves dangerous gaps that attackers exploit.

What I've learned from dozens of similar cases is that compliance frameworks provide minimum standards, not optimal protection. They're designed to ensure basic hygiene, not defend against sophisticated threats. In my practice, I've developed a three-tier approach to bridge this gap: first, meet compliance requirements; second, implement controls that address actual threat models; third, continuously monitor for emerging risks. This approach requires shifting mindset from "Are we compliant?" to "Are we secure?" The difference might seem semantic, but in execution, it's profound. For the e-commerce client, this meant implementing additional monitoring for API endpoints, conducting regular penetration tests beyond compliance requirements, and training developers on secure coding practices not mandated by any standard. The result was a 40% reduction in security incidents over the following year.

Another critical insight from my experience is timing. Compliance audits typically happen annually or quarterly, but threats emerge continuously. I recommend implementing continuous security validation through automated tools and regular threat modeling sessions. In one project last year, we conducted weekly threat modeling with the development team, identifying and addressing 15 potential vulnerabilities before they reached production. This proactive approach cost about 5% more in initial setup but saved an estimated $500,000 in potential breach costs. The key takeaway: don't wait for your next compliance audit to check your security. Make security auditing an ongoing process integrated into your development lifecycle. This shift from periodic to continuous is the foundation of moving beyond compliance.

Understanding Proactive Security: From Firefighting to Fire Prevention

When I first started in security two decades ago, most of my work involved responding to incidents—putting out fires after they'd already caused damage. Over time, I realized this reactive approach was unsustainable. In my current practice, I've shifted entirely to proactive security, which means identifying and addressing vulnerabilities before attackers can exploit them. This isn't just theoretical; I've implemented this approach with over 30 clients across different industries, consistently reducing incident rates by 60-80%. Proactive security involves several key components: threat intelligence, vulnerability management, security testing, and continuous monitoring. Each requires different tools and approaches, which I'll compare in detail. But first, let me explain why this shift matters so much.

A Case Study in Prevention: The Healthcare Provider That Avoided Disaster

In 2025, I worked with a regional healthcare provider that was transitioning to a new electronic health records system. Their compliance team focused on meeting HIPAA requirements for the new system, but I recommended a proactive security assessment before go-live. During this assessment, we discovered that the system's legacy integration components had unpatched vulnerabilities that could allow unauthorized access to patient data. These vulnerabilities weren't apparent in the compliance checklist because they involved third-party components not directly covered by HIPAA. We worked with the vendor to patch these issues and implemented additional monitoring for the integration points. Six months later, we detected attempted exploitation of similar vulnerabilities in other healthcare systems through our threat intelligence feeds. Because we had already addressed the issue proactively, our client remained unaffected while competitors experienced breaches. This case demonstrated the value of looking beyond compliance requirements to actual attack surfaces.

Based on my experience, I recommend three core practices for proactive security. First, implement continuous vulnerability scanning using tools like Nessus or OpenVAS, but don't stop there. I've found that many organizations scan but don't prioritize effectively. In my practice, I use a risk-based approach that considers exploit availability, asset criticality, and business impact. Second, integrate threat intelligence into your security operations. I subscribe to multiple intelligence feeds and correlate them with our internal data to identify emerging threats relevant to our environment. Third, conduct regular penetration tests and red team exercises. I schedule these quarterly for most clients, using different testers each time to avoid familiarity bias. Each approach has pros and cons: automated scanning is comprehensive but can produce false positives; threat intelligence is timely but requires interpretation; penetration testing is realistic but snapshot-based. The combination provides layered protection.

Another important aspect I've learned is organizational culture. Proactive security requires buy-in from leadership and integration with development processes. In one engagement with a fintech startup, we implemented "security champions" within each development team—developers trained in security basics who could identify issues early. This program reduced security-related bugs in production by 70% over nine months. We also established a security metrics dashboard visible to leadership, showing trends in vulnerabilities, mean time to detection, and other key indicators. This transparency helped secure ongoing investment in security initiatives. The lesson: proactive security isn't just about tools; it's about people, processes, and visibility. Without organizational support, even the best technical controls will fail. In the next sections, I'll dive deeper into specific strategies and how to implement them effectively in different scenarios.

Threat Intelligence Integration: Seeing Around Corners

In my practice, I consider threat intelligence the cornerstone of proactive security. It's what allows us to anticipate attacks rather than just respond to them. I've been integrating threat intelligence into security operations for over a decade, and I've seen it evolve from simple malware signatures to complex indicators of compromise and attacker behavior patterns. The key insight I've gained is that effective threat intelligence isn't about collecting more data—it's about collecting the right data and applying it to your specific context. I work with clients to build threat intelligence programs tailored to their industry, technology stack, and risk profile. For example, a retail client needs different intelligence than a healthcare provider, even if they use similar technologies. Let me share how I approach this critical component.

Building a Threat Intelligence Program: Lessons from a Financial Services Client

In 2024, I helped a regional bank establish their first formal threat intelligence program. They had been relying on generic feeds that generated hundreds of alerts daily, most irrelevant to their environment. My first step was to conduct a threat modeling workshop with their security team, identifying their critical assets and most likely attack vectors. We determined that their primary risks involved online banking platforms, mobile applications, and third-party payment processors. Based on this, I recommended subscribing to three specialized intelligence feeds: one focused on financial sector threats, one on mobile application vulnerabilities, and one on supply chain risks. We also set up automated enrichment of internal security events with external intelligence. Within three months, this approach reduced alert volume by 65% while increasing actionable intelligence by 40%. More importantly, it helped them detect and block a sophisticated phishing campaign targeting their customers two weeks before it became widespread.

From this and similar engagements, I've developed a framework for threat intelligence integration that balances comprehensiveness with practicality. First, identify your intelligence requirements based on your business context. I use a simple matrix: what threats are most likely (probability) and what would have the greatest impact (severity)? Second, select intelligence sources that match these requirements. I typically recommend a mix of commercial feeds, open-source intelligence, and industry sharing groups. Third, establish processes for analyzing and applying intelligence. This is where many programs fail—collecting intelligence but not acting on it. I implement regular threat intelligence briefings where we review recent findings and update defensive measures accordingly. Fourth, measure effectiveness through metrics like time from intelligence receipt to defensive action, or reduction in successful attacks against warned-about threats.

I also want to address common pitfalls I've encountered. Many organizations treat threat intelligence as a separate function from security operations. In my experience, this creates silos that reduce effectiveness. Instead, I integrate intelligence analysts directly into security operations centers or incident response teams. Another mistake is focusing only on technical indicators like IP addresses or file hashes. While these are important, I've found that understanding attacker tactics, techniques, and procedures (TTPs) provides more durable protection. For example, knowing that a particular threat group uses spear-phishing with malicious documents allows you to implement controls against that technique, even as specific indicators change. Finally, don't underestimate the value of sharing intelligence with peers. I participate in several industry Information Sharing and Analysis Centers (ISACs), and the collaborative insights have helped my clients prevent attacks multiple times. The key is building relationships before you need them—intelligence sharing is most effective when based on trust established during calm periods.

Continuous Security Monitoring: The Always-On Advantage

One of the most significant shifts I've advocated for in my career is moving from periodic security assessments to continuous monitoring. When I started consulting, most organizations conducted security reviews annually or quarterly. The problem, as I quickly discovered, is that threats don't operate on a schedule. A vulnerability disclosed today could be exploited tomorrow, not in three months when your next audit is scheduled. In my practice, I've implemented continuous monitoring programs for organizations ranging from small startups to Fortune 500 companies, consistently finding that this approach reduces mean time to detection (MTTD) by 70-90%. Continuous monitoring isn't just about technology; it involves people, processes, and cultural changes. Let me explain how I approach this transformation based on real-world experience.

Implementing Continuous Monitoring: A Manufacturing Case Study

In late 2023, I worked with an industrial manufacturing company that had experienced a production disruption due to a ransomware attack. Their security monitoring consisted of weekly log reviews and monthly vulnerability scans—clearly insufficient for their operational technology environment. We designed and implemented a continuous monitoring program over six months. The first phase involved instrumenting their critical systems: we deployed network monitoring on their control systems, implemented endpoint detection on engineering workstations, and set up centralized logging for all industrial devices. The second phase focused on detection rules: we created alerts for suspicious activities like unauthorized configuration changes or unusual network traffic patterns. The third phase involved response procedures: we trained their operations team on recognizing security incidents and established escalation paths. Within four months of full implementation, they detected and contained three attempted intrusions before any damage occurred. The program cost approximately $150,000 to implement but prevented an estimated $2 million in potential downtime.

Based on this and similar projects, I recommend a phased approach to continuous monitoring. Start with your most critical assets—what would cause the most damage if compromised? For most organizations, this includes customer data systems, intellectual property repositories, and operational technology. Implement monitoring for these first, then expand coverage over time. I typically use a combination of tools: Security Information and Event Management (SIEM) for log aggregation and correlation, Endpoint Detection and Response (EDR) for host monitoring, and Network Detection and Response (NDR) for traffic analysis. Each has strengths and limitations: SIEM provides comprehensive visibility but requires significant tuning; EDR offers deep endpoint insight but can impact performance; NDR detects network-based threats but may miss encrypted traffic. The right mix depends on your environment and risk profile.

Another critical lesson I've learned is that continuous monitoring requires continuous improvement. When I first implemented these programs, I made the mistake of setting them up and considering them complete. In reality, attackers evolve their techniques, and your monitoring must evolve too. I now schedule regular reviews of detection rules, typically quarterly, to ensure they're still effective. I also conduct purple team exercises where my red team attempts to bypass our monitoring while the blue team defends. These exercises have revealed blind spots in every organization I've worked with. For example, in one exercise last year, we discovered that our monitoring missed lateral movement through legitimate administrative tools. We updated our rules to detect abnormal usage patterns of these tools, closing a significant gap. The key insight: continuous monitoring isn't a project with an end date; it's an ongoing program that requires maintenance and adaptation. This mindset shift is essential for long-term success.

Vulnerability Management: Beyond Patching Checklists

Vulnerability management is often reduced to a simple process: scan, patch, repeat. In my experience, this simplistic approach misses the complexity of modern environments. I've worked with organizations that patched every vulnerability on schedule yet still suffered breaches because they missed critical context about exploitability, asset value, or attack paths. True vulnerability management requires understanding not just what vulnerabilities exist, but which ones matter most to your specific environment. Over the past decade, I've developed a risk-based approach that prioritizes remediation based on actual business impact rather than generic severity scores. This approach has helped my clients reduce their exploitable vulnerability window by 80% while optimizing remediation resources. Let me share how this works in practice.

Risk-Based Prioritization: A Technology Company's Transformation

In early 2024, I consulted for a SaaS company struggling with vulnerability overload. Their scanning tools identified thousands of vulnerabilities monthly, but their small security team could only patch a fraction. They were using Common Vulnerability Scoring System (CVSS) scores for prioritization, which led them to focus on high-scoring vulnerabilities in non-critical systems while missing lower-scoring vulnerabilities in critical components. We implemented a risk-based approach over three months. First, we mapped their assets and assigned business criticality scores based on factors like data sensitivity, revenue dependency, and regulatory requirements. Second, we enriched vulnerability data with threat intelligence about active exploitation. Third, we analyzed attack paths to understand which vulnerabilities could be chained together for maximum impact. This analysis revealed that a medium-severity vulnerability in their authentication service, when combined with a low-severity issue in their web application firewall, could allow full system compromise. We patched this combination first, preventing a potential breach. Over six months, this approach reduced their mean time to remediate critical vulnerabilities from 45 days to 7 days while decreasing overall vulnerability counts by 60%.

From this engagement and others, I've identified three key components of effective vulnerability management. First, context matters more than scores. CVSS and similar scoring systems provide a starting point, but they don't consider your specific environment. I always supplement these scores with internal context: Is the vulnerable system internet-facing? Does it contain sensitive data? Are there compensating controls? Second, timing is critical. The window between vulnerability disclosure and exploitation is shrinking. According to research from the Ponemon Institute, the average time from vulnerability disclosure to exploitation decreased from 45 days in 2020 to 15 days in 2025. This means traditional monthly or quarterly patching cycles are inadequate for critical systems. I recommend continuous vulnerability assessment with automated scanning integrated into development pipelines. Third, measurement drives improvement. I track metrics like vulnerability age, remediation rate, and re-emergence rate to identify process gaps. For example, if vulnerabilities keep reappearing after patching, it might indicate configuration drift or inadequate testing.

I also want to address common challenges I've encountered. Many organizations struggle with vulnerability management in cloud environments, where traditional scanning tools may not have complete visibility. For cloud workloads, I recommend agent-based scanning combined with infrastructure-as-code analysis. Another challenge is third-party risk—vulnerabilities in vendor software or services. I've developed a vendor risk assessment framework that includes requiring vendors to demonstrate their vulnerability management practices. Finally, don't forget about people and process vulnerabilities. Technical vulnerabilities get most attention, but misconfigurations, weak credentials, and social engineering often provide easier attack paths. I include these in vulnerability management through regular configuration reviews, credential audits, and phishing simulations. The holistic approach recognizes that vulnerabilities exist across people, processes, and technology, and effective management must address all three dimensions.

Security Testing Methodologies: Comparing Approaches

In my practice, I use multiple security testing methodologies to provide comprehensive coverage. Each approach has strengths, weaknesses, and appropriate use cases. Over the years, I've developed a testing strategy that combines automated scanning, manual penetration testing, red team exercises, and bug bounty programs based on the client's maturity level and risk profile. I've found that no single methodology catches all issues, but the right combination provides defense in depth. Let me compare the approaches I use most frequently, drawing on specific examples from my experience to illustrate when each is most effective.

Penetration Testing vs. Red Teaming: A Healthcare Comparison

In 2025, I conducted both penetration testing and red team exercises for a large hospital system. The penetration test followed a structured methodology: we defined scope (their patient portal and associated systems), used automated tools to identify vulnerabilities, then manually exploited them to demonstrate impact. This approach identified 42 vulnerabilities, including SQL injection in a search function and insecure direct object references in patient records. The red team exercise took a different approach: we simulated a determined adversary attempting to steal patient data without prior knowledge of the systems. Our red team used social engineering to gain initial access, then moved laterally through the network, eventually exfiltrating simulated patient data. This exercise revealed different issues: weak password policies allowing credential reuse, insufficient network segmentation between clinical and administrative systems, and lack of detection for lateral movement. Both approaches were valuable but served different purposes. The penetration test provided a comprehensive assessment of specific systems' security, while the red team exercise tested the organization's overall detection and response capabilities.

Based on this and similar comparisons, I recommend the following approaches for different scenarios. First, automated vulnerability scanning is best for broad coverage and regular assessment. I use tools like Nessus, Qualys, and OpenVAS for continuous scanning of known vulnerabilities. These tools are fast, comprehensive for known issues, and scalable. However, they miss logical flaws, business logic vulnerabilities, and novel attack techniques. Second, manual penetration testing is ideal for in-depth assessment of critical systems. I typically conduct these quarterly for high-risk applications or after major changes. Penetration testing finds issues automated tools miss but is time-consuming and expensive. Third, red team exercises test detection and response capabilities across people, processes, and technology. I recommend these annually for mature organizations. They're the most realistic but also the most disruptive. Fourth, bug bounty programs leverage external researchers for continuous testing. I've helped several clients establish these programs, which provide ongoing coverage but require careful management to avoid overwhelming your team with low-quality reports.

Another important consideration is tester selection. I've worked with internal teams, external consultants, and hybrid approaches. Each has advantages: internal testers understand the environment deeply but may suffer from familiarity bias; external testers bring fresh perspectives but require time to understand context. For most clients, I recommend a hybrid model: internal teams for regular testing, supplemented by external experts for annual assessments or specialized testing. I also emphasize the importance of scope definition. Testing everything is impossible, so I help clients prioritize based on risk. For example, internet-facing applications get tested more frequently than internal systems, and critical business functions receive more attention than ancillary services. Finally, remediation tracking is essential. I've seen many organizations conduct tests but fail to fix findings. I implement formal tracking processes with clear ownership and deadlines. The most effective programs treat security testing not as an audit but as a quality improvement process integrated into development lifecycles.

Building a Security-First Culture: Beyond Technical Controls

Throughout my career, I've learned that technical controls alone cannot guarantee security. The most sophisticated tools fail if people bypass them or make poor decisions. Building a security-first culture is therefore essential for proactive security. I've helped organizations transform from viewing security as IT's problem to making it everyone's responsibility. This cultural shift requires leadership commitment, ongoing education, and embedding security into business processes. In my experience, organizations with strong security cultures experience 50% fewer security incidents and recover from incidents 30% faster. Let me share practical strategies for fostering this culture based on successful implementations.

Cultural Transformation: A Retail Company's Journey

In 2024, I worked with a national retail chain that had suffered multiple security incidents despite having decent technical controls. The root cause was cultural: employees saw security as hindering their work, so they found workarounds. For example, sales staff shared passwords to access point-of-sale systems faster, and marketing teams used unauthorized cloud services to share large files. We implemented a cultural transformation program over nine months. First, we secured executive sponsorship by demonstrating how security incidents impacted revenue and brand reputation. The CEO became our champion, regularly communicating about security importance. Second, we made security relevant to each role through tailored training. Instead of generic cybersecurity awareness, we showed sales staff how security protected their commissions from fraud, and marketing teams how it safeguarded campaign data. Third, we integrated security into business processes. For instance, we created a streamlined process for approving cloud services that balanced security with business needs, eliminating the need for shadow IT. Fourth, we celebrated security wins. When an employee reported a phishing attempt that prevented a potential breach, we publicly recognized their contribution. Within a year, reported security policy violations decreased by 75%, and employee-reported security issues increased by 300%.

From this engagement, I've identified key elements for building security culture. Leadership commitment is non-negotiable. I work with executives to understand security's business impact and communicate consistently about its importance. Education must be continuous and engaging. I've moved from annual training sessions to micro-learning modules delivered regularly. For example, monthly five-minute videos on current threats or quarterly simulated phishing campaigns with immediate feedback. Accountability matters at all levels. I help organizations establish clear security responsibilities in job descriptions and performance reviews. For technical staff, this might include secure coding practices; for executives, it might involve risk acceptance decisions. Transparency builds trust. I encourage organizations to share security metrics and incidents (appropriately anonymized) to demonstrate that security is a shared challenge, not something hidden in the IT department.

I also want to address common cultural barriers I've encountered. Many organizations treat security as a compliance requirement rather than a business enabler. I reframe security as enabling innovation by providing confidence to try new things safely. Another barrier is the perception that security slows things down. I address this by integrating security early in processes rather than as a last-minute checkpoint. For example, involving security in design reviews rather than just penetration testing before launch. Finally, measurement is crucial for cultural change. I track cultural indicators like security training completion rates, employee-reported issues, and security policy compliance alongside technical metrics. These indicators help identify areas needing attention and demonstrate progress to leadership. The ultimate goal is making security intuitive—the default way of working rather than an added burden. This cultural foundation makes all technical controls more effective and sustainable over time.

Implementing Your Proactive Audit Program: A Step-by-Step Guide

Based on my experience helping dozens of organizations implement proactive security auditing, I've developed a practical step-by-step approach. This isn't theoretical—I've used this framework with clients ranging from startups to enterprises, adapting it to their specific contexts. The key is starting where you are and making incremental improvements rather than attempting a perfect implementation all at once. I typically recommend a 12-month roadmap with quarterly milestones. Let me walk you through the process I use, including common pitfalls to avoid and how to measure success along the way.

Phase 1: Assessment and Planning (Months 1-3)

The first phase involves understanding your current state and defining your target state. I begin with a comprehensive assessment that goes beyond compliance checklists. For a client last year, this assessment revealed that while they had strong perimeter defenses, their internal network had minimal segmentation, allowing lateral movement if the perimeter was breached. We also interviewed stakeholders to understand business priorities and constraints. Based on this assessment, we developed a prioritized roadmap. The highest priority was implementing network segmentation for critical systems, which we estimated would reduce potential breach impact by 70%. We also established metrics for success: reducing mean time to detect incidents from 30 days to 7 days, decreasing critical vulnerabilities by 50%, and increasing security testing coverage from 20% to 80% of systems. This planning phase is critical because it aligns security initiatives with business objectives and sets realistic expectations.

During planning, I emphasize several key principles. First, focus on risk reduction rather than perfection. It's better to address the highest risks adequately than to attempt comprehensive coverage and fail. Second, secure executive sponsorship and budget commitment upfront. I've seen many initiatives stall when funding runs out after the initial assessment. Third, build cross-functional teams. Security can't succeed in isolation—involve IT, development, operations, and business units from the beginning. Fourth, start with quick wins to build momentum. For the client mentioned, we implemented basic network monitoring in the first month, which immediately detected several misconfigured devices. These early successes helped maintain enthusiasm for the longer-term work.

Phase 2: Foundation Building (Months 4-6)

The second phase establishes the foundational capabilities for proactive auditing. This typically includes implementing continuous monitoring, vulnerability management, and basic threat intelligence. For most organizations, I recommend starting with monitoring because it provides immediate visibility. We deploy a SIEM or similar tool, configure essential logs, and establish alerting for critical events. Simultaneously, we implement vulnerability scanning with risk-based prioritization. I've found that trying to do everything at once leads to overwhelm, so we focus on these core capabilities before expanding. During this phase, we also establish processes and documentation. For example, we create runbooks for common security events and define roles and responsibilities. Training is essential—we conduct workshops for security staff and broader awareness sessions for all employees.

A common challenge during this phase is tool selection and integration. I recommend starting with existing tools where possible rather than buying new ones. Many organizations already have capabilities they're not using effectively. For instance, one client had purchased an EDR solution but only used it for antivirus. We expanded its use to include behavioral detection and incident response, getting more value from their existing investment. Another challenge is balancing depth with breadth. It's tempting to monitor everything superficially, but I advocate for deep monitoring of critical assets first. We identify the 20% of assets that would cause 80% of damage if compromised and instrument those thoroughly before expanding coverage. This approach provides maximum risk reduction for minimum initial effort.

Phase 3: Maturation and Expansion (Months 7-12)

The third phase involves maturing capabilities and expanding coverage. By this point, basic monitoring and vulnerability management should be operational. We now enhance these with more sophisticated detection rules, integrate threat intelligence, and implement regular security testing. We also expand coverage to more systems and begin addressing cultural aspects through training and process integration. For many organizations, this phase includes implementing a security operations center (SOC) or partnering with a managed security service provider (MSSP). The choice depends on resources and expertise—I've helped clients with both approaches. During this phase, we also refine metrics and reporting to demonstrate value to leadership. I recommend monthly security dashboards that show trends in key areas like vulnerabilities, incidents, and control effectiveness.

The final step is establishing a continuous improvement cycle. Security isn't a project with an end date—it requires ongoing adaptation. We schedule regular reviews of our program, typically quarterly, to assess what's working and what needs adjustment. We also conduct tabletop exercises to test our response capabilities and identify gaps. The goal is creating a self-sustaining program that evolves with changing threats and business needs. From my experience, organizations that complete this 12-month journey typically achieve 70-80% reduction in security incidents and significantly improved resilience against attacks. The key is persistence—proactive security requires ongoing effort, but the payoff in reduced risk and increased confidence is substantial.