Penetration testing cost is directly correlated to how long an engagement takes to complete. Sometimes the target system or organisation is so vast that a review that achieves what we’d consider “complete” coverage is prohibitively expensive. This article discusses how Pulse Security tackles timeboxed testing engagements. We’ll discuss the problem, how testing is prioritised in an engagement with reduced time-frames, the importance of transparency between penetration testers and clients, and what you can expect from a timeboxed engagement.

The main goal of penetration testing is identifying vulnerabilities, missing security hardening steps, and analysis of the inherent security implications in architectural choices. Our goal is to assess as much functionality as possible, thoroughly as possible, so we can explain as many of these issues as we can and the client can improve the security posture of the system by understanding and remediating these issues.

Engagements are scoped and sized to allow the consultant enough time to assess every data input and security control to the extent where we can confidently reason about the security of the system.

Imagine a system where there are thousands of hosts, dozens of applications, tens of thousands of API endpoints. How long would it take a tester to definitively assess all areas where an attacker may introduce malicious data into these systems, and all the security controls that keep the platform safe? The answer is often months worth of testing time. Given that penetration testing cost is directly correlated to engagement time, this means a large testing cost. Also consider an organisation where testing budgets are constrained, how can these organisations benefit from quality security assurance?

Add in the complexity of operating systems, frameworks, networking logic, third-party libraries, cloud computing, and our ability to definitively reason about a system is impacted even further. Even formally verified EAL7 systems (where you can mathematically prove a system’s intended behaviour) can still be misused and lead to security issues. This raises issues with the concept of complete testing coverage being achievable at all. We could potentially test for ∞ time and, naturally, we need a way to improve the security of the target systems without spending $∞. Thus, timeboxing.

If we cannot definitively reason about a system, then we cannot surface a definitive list of issues, so instead we need to be transparent about where our priorities are and what we looked at. This means that we build our shared understanding of the systems we’re responsible for, and can keep improving on cyber security and safety over time.

But how do we know what to prioritise?

How are engagements timeboxed?

Before we get into the specifics, let’s talk about how engagements are generally timeboxed during the scoping or pre-sales phase on an engagement. Robust scoping should understand the attack surfaces and extent of the target (application, API, network, product, or organisation - depending on engagement type) well enough to determine how long an engagement with robust testing coverage would likely take. At Pulse Security this can mean looking at design documents if they’re available, source code, exploring applications with test access, meeting with the client’s team to discuss the review, and possibly performing initial network scans. This is before any testing is performed, and is handled as part of the technical sales process.

Performing accurate scoping can make the quote quite alarming (I have yet to write a quote for $∞, for the record…). A network or API that has grown organically over years may have an enormous attack surface, and that will take an uncomfortably large amount of time (and thus cost) to review thoroughly.

The time requirement needs to be reduced. Since we try to build a solid understanding of target systems during scoping, this is done by discussing the issue and specifying certain focal points of the engagement and de-prioritising others. Or, by setting a reduced time-limit for the engagement. Timeboxing.

The Standards Problem

Reading cyber security standards and methodologies is something I do a lot. These standards get incorporated into our internal methodologies, and extending the testing guidance where the industry standards fall short should be a process familiar to most penetration testers.

All the major industry standards NIST SP 800-115, OWASP WSTG/MSTG, PCI DSS Penetration Testing Guidance, PTES, OSSTMM have a problem in common. They don’t define in a measurable or repeatable way what to prioritise during a penetration test. Here’s a quick analysis:

• NIST SP 800-115 addresses prioritisation only at the programme level - choosing which systems to assess first based on impact rating and assessment age.
• The OWASP Web Security Testing Guide (WSTG v4.2) is a catalogue of test cases organised by vulnerability class, but provides no guidance on ordering or weighting those classes. Defining a definitive list of attack surfaces and where the inputs for these test cases should go is also defined at a rather high level in the WSTG, but that’s something I’ll discuss further in another article…
• The PCI DSS Penetration Testing Guidance similarly defines scope and methodology phases (pre-engagement, engagement, post-engagement) without any internal prioritisation logic.
• The Penetration Testing Execution Standard (PTES) follows the same pattern: seven phases, none of which explain what to test first when time is short. PTES has also not received meaningful updates since approximately 2012 and does not address modern cloud, container, or API attack surfaces.
• OSSTMM 3 suggests rather than prescribing what to test, it defines a quantitative attack surface metric (the RAV) and formal error types. There are different ways this can go wrong. OSSTMM names “Sampling Error” (error type 9) as the condition that arises when time constraints or authority bias causes a tester to cover only a subset of a scope, and says this causes misrepresentation of the overall security posture. OSSTMM’s answer to the problem is brutal completeness tracking and transparent reporting of what was not tested, not a prioritisation framework.

Sampling Error - The target is a biased sample of a larger system or a larger number of possible states. This error normally occurs when an authority influences the operational state of the target for the duration of the test. This may be through specific time constraints on the test or a bias of testing only components designated as “important” within a system. This type of error will cause a misrepresentation of the overall operational security.

The OSSTMM guidance here looks like the best option: create a definitive list of inputs and include this in the testing notes. This works for simpler targets, but once things get more complicated and more integrated as modern systems like to do, defining this list could take the whole engagement or longer. Sometimes, defining that list of where attacker-controllable data is going could take forever, and we’re back to the $∞ problem.

Which brings us to the real question: if standards don’t solve this, what do practitioners actually do?

Limitations of Intuition, Experience and the Hacker Mindset

Experienced testers often draw on their intuition to target things that feel like they contain vulnerabilities. This isn’t exactly good engineering, one could argue it’s closer to witchcraft! The consultant assumes to know what’s likely vulnerable because it elicits various feelings, but they don’t really pay much mind to everything that felt vulnerable but was indeed benign. This feeds into our ‘hacker mindset’ biases, where finding security vulnerabilities is attributed to how many “hacker” thinking patterns the consultant employs.

I find it tempting to try to engineer my way through these kinds of problems. If I could define the perfect process, play-book, automation, etc, then the prioritisation problem is solved. Unfortunately, with so many engagement types and the massive complexity of tracking exactly where a byte of attacker-controllable data goes, the reality is the best we can do is provide smart guidance on prioritisation. The consultant’s experience, skills and intuition will continue to be key in delivering a quality penetration test (time constrained or not) for a specific target. In an ideal organisation, the consultant will build these skills during an apprenticeship period where they work alongside experienced team members. Our goal was to lessen the reliance on intuition, provide some guard-rails, and explain why transparency is so critical.

You can’t replace experience with documentation - Fobski

What we really have here is an intersection of several problems in computer science and social science. On the comp-sci side, accurate end-to-end taint tracking across a complex system, the halting problem, and so forth. On the social side, the consultant is attempting to use their own experience, intuition and manage their own biases to produce objectively good technical analysis outcomes.

This is why there is such variance in penetration testing approach and output across different testing firms. This is also why the wider IT industry seems to have uncertainty around what exactly a penetration tester is doing.

The Pulse Security Timeboxing Methodology

Uncertainty around testing priority causes several problems. The potential for not enough testing time and uncertain priorities resulting in missed vulnerabilities and misrepresenting the security posture of a system is clear, but the additional pressure and load on technical security testers is often overlooked. Testers already deal with impostor syndrome, mental fatigue and the feeling of not achieving enough. Add in time pressure and this is a recipe for stress, burnout and a reduction in quality of work.

We developed a detailed internal methodology to guide our consultants during timeboxed engagements to help address these issues. The goal of the methodology is to provide the guidance around prioritisation and reporting transparency requirements. This methodology also sets the standard for communicating what happened during the testing, what we prioritised, and what the next steps for testing are. This means the report improves our shared understanding and is not simply an exception-based list of findings.

I’ll share some of those details here so other practitioners and our clients are clear on how we tackle this specific problem.

Every timeboxed engagement involves a trade-off between competing goals:

• Finding impactful issues. Severe information leakage, authentication bypasses, remote code execution. Our top priority is always finding and helping remediate issues that are likely to cause real harm.
• Finding issues that are easy and fast to discover. Issues with low opportunity-cost for attackers, and hardening and architectural controls which are fast to identify.
• Issues that are both easy to find and impactful. This is the worst-case scenario for the client. These are issues which are likely to be exploited by a real opportunistic attacker. Think unpatched software with known public vulnerabilities.

The balance is important because we don’t want to spend all the time chasing down hardening issues that can be easily detected, but we also don’t want to focus all our time on potential higher severity issues and miss meaningful hardening recommendations. Naturally, issues that are both impactful and easy to find are generally the priority.

A tester who spends all their time chasing potential high-severity issues might miss valuable hardening controls. A tester who focuses only on defense-in-depth controls might leave the critical vulnerabilities undiscovered. A tester who spends all their time exploring a potentially novel new vulnerability class to the detriment of known issues is about to have an unpleasant conversation with their tech lead!

The “art” of penetration testing is balancing these competing priorities, and being honest about where that balance ended up for each individual engagement. That last part is critical, because that’s how other security professionals and the client themselves know what was actually done during an engagement.

The tier system

We structure timeboxed work into four tiers: P0 through P3. The tiers define what gets looked at first, not how deeply. Depth within each tier is described separately using coverage levels (ideal, good, mediocre, poor). The tiers are ordered by the cost of skipping them: skipping P0 means you don’t know what you’re testing and no real analysis can be done; skipping P1 means you may miss the issues most likely to cause a real-world compromise.

P0 - Attack surface mapping and initial analysis. A tester needs to understand what they are testing. This means building an initial attack surface table. This is a structured inventory of exposed interfaces, what each interface does, how it is exposed, and what controls defend it (Howard et al are good reading around attack-surface concepts). An attack surface is the combination of an interface that accepts data (an API endpoint, a network port, a user input form) and the context in which it is reachable (public internet, internal network, authenticated session only). A second table also captures an authentication matrix: what user roles exist and what each role should have access to.

The output of P0 directly drives all subsequent prioritisation decisions. Without it, all testing decisions default to intuition and luck and we lose the most fundamental understanding that all further work is built on.

P1 Known vulnerabilities and critical security controls. Two categories of issue share P1 status because both are likely to show a path to a real-world compromise:

• Exploitable known vulnerabilities are publicly documented and exploitable flaws in the software components making up the target. These are the issues attackers scan for first, and often behind real-world breaches..
• Critical security controls are the authentication, authorisation, and access controls that form the primary security boundary of the target. A broken authentication mechanism or a missing authorisation check is a direct path to impact and generally represents a flaw in a fundamental control, not just an exploitable bug.

P2 Input-based attacks and information disclosure. Once P0 and P1 is covered, the remaining time goes toward testing how the application handles attacker-controlled input across its attack surfaces. This is where attacks against network ports and protocols, SQL injection, command injection, SSRF, information disclosure, and similar vulnerability classes live.

An important note on input-based testing. Testing standards like OWASP WSTG, ASVS, and training materials like CTFs and Hack The Box focus on specific vulnerability classes and test cases. Unfortunately, as a professional security tester you cannot decide to simply “find all the SQL injection” in isolation, or focus on just the “important” bugs. This is a fairly serious misunderstanding of the vulnerability testing process. In a real-world assessment, determining whether any input-based vulnerability exists at a given location requires the same process regardless of vulnerability class: enumerate the inputs, attack them systematically, and triage responses to determine whether any vulnerability is present. There is no good shortcut that reliably finds high-severity command injection without also finding medium-severity reflected XSS and so forth at the same input. The prioritisation in P2 is therefore about which inputs to examine first, not which vulnerability types to look for.

Also at P2: A structured pass with automated tooling (dynamic scanners, source code analysers, dependency checkers, cloud configuration auditors). Automated tools are de-prioritised relative to manual P1 work because they surface issues that are easy to detect programmatically, not necessarily the most impactful issues. They are still worth running, but a lower priority than the P1 items.

Automation is a tricky one and will be covered more in a future article. Automated tools that remove the testers agency or understanding of a system can often be a net negative to the testing when misused. One thing that catches out many new penetration testers is an automated tool (especially a new shiny automated tool) that simply returns concrete output about a vulnerability. Potentially useful as a “may as well” automated scanning step; however, for a penetration tester the key is to analyse a system and build an understanding of how it really works. This is so the penetration tester can reason about the system, surface more issues and present them with accurate analysis regarding impacts and technical severity. Unfortunately, automated tools can often add limited additional understanding. Sometimes all the tester learns is that they ran the tool. A skilled tester is constantly weighing whether a specific tool adds technical value or just an illusion of further coverage.

P3 Continued coverage. Once P0 through P2 are done to whatever coverage level time allows, any remaining time goes to broadening coverage further: deeper input testing, additional attack surfaces, less-exposed interfaces that were deprioritised earlier. At this point the overall testing methodology for the target, aiming to achieve complete coverage, takes over.

The P0–P3 tier structure gives a consistent answer to the question of what to test first: understand the attack surface (P0), check known vulnerabilities and critical security controls (P1), then test input handling and information disclosure systematically (P2).

The tier table

This table below shows the four tiers and the four coverage levels that can apply within each tier. We push for ideal coverage on the most exposed attack surfaces while accepting mediocre coverage on lower-priority ones is a core mechanism, and document the trade-offs in the report.

Tier	Ideal	Good	Mediocre	Poor
P0 Attack surface mapping	Full attack surface tables for all components; complete authentication matrix for all roles; threat model documented; output shared in report	Attack surface tables for primary components; authentication matrix for key roles; priority list maintained	High-level inventory of exposed interfaces; prioritisation based on intuition	Testing begins with no mapping; limited to automated tool runs with poor understanding of what is exposed or why
P1 Known vulnerabilities	Full tech stack fingerprinted across all attack surfaces; all CVE results manually triaged; Exploited-in-the-wild findings confirmed exploitable or mitigated	Major components fingerprinted across primary attack surfaces; automated scanning run; exploitable CVEs triaged manually	Automated tooling run against primary attack surfaces only; no manual triage	No deliberate version fingerprinting beyond an automated scan; only passively disclosed indicators checked
P1 Critical security controls	All authentication mechanisms tested end-to-end; full authorisation matrix verified for every role against every sensitive function; all attack surface minimisation controls confirmed functioning	All authentication mechanisms tested; authorisation spot-checked on sensitive and administrative functions; automated tool (e.g. Autorize, automated network testing tooling) run across the full authenticated session	Login mechanisms tested; subset of administrative functions checked for authentication bypasses	Only unauthenticated access to obviously sensitive endpoints checked; no privilege escalation or horizontal access testing
P2 Input-based attacks	Every input across all attack surfaces reviewed thoroughly; outliers triaged; all data-processing flows reviewed manually	All inputs receive some automated attention; majority of data-processing flows reviewed manually	Majority of inputs receive some automated attention; only prioritised inputs reviewed manually	Automated tooling run; a handful of inputs reviewed manually based on intuition
P2 Information disclosure	All inputs reviewed for unintended disclosure; sensitive file locations and error responses checked across all attack surfaces; P1 access control findings cross-referenced for disclosure impact	Common disclosure locations checked (error responses, debug pages, sensitive file paths, directory listings); P1 access control findings reviewed for data exposure	Obvious disclosure vectors only	No deliberate disclosure testing; findings incidental to other testing
P3 Remaining Methodology	As defined in the specific methodology

We can combine the priority table above with the attack surfaces tables we build during the initial testing and build a clear picture of what was really assessed during the penetration test.

Transparency and Communication - The Ideal Relationship Between Penetration Tester and Client

OSSTMM had the right idea. Transparency is key. If we share our thought processes, prioritisation, and where we feel the target can benefit from further analysis, we can get good assurance results and help clients to take the next step in their security journey with a stronger understanding and nuanced analysis.

The ideal client relationship is one where this information flows in both directions. Clients who can explain their system architecture, share source code or server access, and clarify what is sensitive to help the tester prioritise more accurately. Testers who explain their prioritisation decisions help clients understand what they are getting and make informed decisions about where to invest further analysis.

Practically, this means the scope of work should include agreed expectations about coverage and depth, not just a list of targets. Good communication between the tester and client are critical, especially on longer engagements, to confirm priorities are still correct as the tester learns more about the system.

Being open about limitations is a professional standard, not a concession. A budget conscious assessment that is honest about what it covered and what it did not is more useful to a client than a report that implies complete coverage it does not have.

Increasing Testing Efficacy

The tester’s time is the constraint. Anything that reduces time spent on reconnaissance, content discovery, or understanding system structure directly increases the time available for actual vulnerability analysis. This also includes anything that can improve how reliably we can identify vulnerabilities. In most instances, we’re talking about using reverse-engineering, code analysis and research techniques to identify vulnerabilities that “black-box” testing is far less likely to find. This is a whole other article, and I’m looking forward to writing that at some point.

Here are some tricks we use on almost all of our engagements:

Source Code Access. Code review changes the dynamic at almost every tier. In P0 it allows a tester to build accurate attack surface tables without guessing URLs - API route lists, authentication middleware patterns, and data-handling logic are all visible directly. In P1 it enables dependency analysis and checks for known vulnerable code patterns (unsafe deserialization, string concatenation into SQL queries, and so on). In P2 it lets the tester identify input handling and sensitive data flows quickly rather than inferring them from observed behaviour. A tester working with source code will build a more complete attack surface picture in the same amount of time, or an equivalent picture in less time.

Server and environment access. Access to back-end servers, cloud consoles, network infrastructure and log data provides similar benefits. Log data helps validate whether test payloads are reaching the intended code paths, which removes guesswork when something returns an unexpected response. Cloud console access means configuration issues can be confirmed directly rather than inferred from external behaviour. Network equipment and server access serves a similar purpose to source-code access. In network-based testing, this lets us find and confirm issues quickly by investigating specific configurations, and when targeting a specific service allows for targeted reverse-engineering.

Open communication. Consultants should be asking detailed questions during scoping and testing about system architecture, data flows, authentication design, and what the application considers sensitive. Clients who engage with these questions reduce the time the tester spends building an understanding of the system from the outside, and we end up building a stronger shared understanding together. We’ll look at any available design documentation, hold kick-off meetings and stay in contact with clients through shared chat channels like Teams/Slack/whatever while testing to figure out systems quicker.

Improved shared context from the client is effectively a free improvement to testing coverage. This doesn’t require more budget, it requires preparation and willingness to be open about how the system works.

What to expect in the Report

A penetration test report is not simply a list of findings. The report also needs context about what was done and where. A report that only lists exceptions (vulnerabilities found) without explaining what was examined and what wasn’t, gives the reader no way to calibrate how much confidence to place in the testing results.

For Pulse Security this generally means detailed attack surface tables and appendices that explain the target, along with discussions in summary sections around engagement priorities and coverage levels. Due to the breadth of possible target systems, writing a definitive table template (here I go trying to engineer a perfect process again!) that can show coverage levels based on our internal tier system isn’t feasible. Too much is lost by shoehorning the consultants into a rigid structure. We found the sweet-spot was detailing attack surfaces at a high level on most engagements, including more specific information where appropriate and feasible, and allowing the consultant to discuss their prioritisation and coverage levels in the summaries.

Specifically, expect the following in a timeboxed engagement report:

Attack surface inventories. A list or table of the interfaces identified during P0 (API endpoints, exposed services, cloud assets, application interfaces, network protocols) and which were prioritised for testing. This tells you what the tester was working with and forms the basis for understanding coverage. In some cases the attack surface information can be very detailed (down to the specific data input location) if the target is particularly well constrained. In broader engagements, this summary could include higher level tables and commentary from the tester based on their understanding of the system’s attack surfaces. Where attack surface appendices are incomplete, incomplete with honest caveats is better than nothing. A partial list with notes on what remains to be analysed is more useful to the next person who picks up the work.

Ongoing security program summaries. This guidance is written for whoever will be continuing the security program for the target. This could be the client’s internal team, a different firm, or Pulse Security equally. The goal is to leave the reader’s understanding of the system in a better state than it was before the engagement, and that includes next steps to take to improve the security testing program.

Representative samples rather than definitive lists. Some findings may identify a vulnerable pattern and a representative example rather than a definitive list. This is helpful when under time pressure, leaving time for broader coverage.

Potentially Less Technical Root Cause Analysis. Root cause analysis is valuable and on a well sized engagement the consultants will have enough time to dig deep into why a specific vulnerability occurred. But, it’s not always the highest-value use of limited time. Explaining what the vulnerability is and how to fix it takes priority over explaining exactly how it got introduced. A well written finding will have enough information for the technical reader to reproduce the issue themselves, look for further instances of the same vulnerability, and determine the root cause either way.

What a report from a timeboxed engagement should never do is imply complete coverage it does not have. A clean result in a section where only poor or mediocre coverage was achieved does not mean the system is secure in that area. The report should make this distinction clearly.

The standards have something to say around the importance of transparency in reporting:

NIST SP 800-115 8 and the PCI DSS Penetration Testing Guidance 5 both stress that the report must clearly document scope boundaries, what was and was not tested, and the methodology used to arrive at findings. OSSTMM sets the highest standards: A formal “Completion Status” section explicitly listing which channels and modules were tested to completion, which were not, and why. Partial testing could be accepted as a valid audit but only with disclosure and information on what wasn’t tested. OSSTMM operates under the assumption that building definitive lists of attack surfaces for a target is possible, which isn’t always the case.

OWASP ASVS v5 addresses this in its verification reporting requirements too, noting that exception-based reporting alone is insufficient and that reports should communicate scope boundaries and testing coverage alongside findings:

Verification reporting
Traditional penetration testing reports issues “by exception,” only listing failures. However, an ASVS certification report should include scope, a summary of all requirements checked, the requirements where exceptions were noted, and guidance on resolving issues. […]
Scope of Verification
[…]
Certifying organizations can choose their testing methods but should disclose them in the report and this should ideally be repeatable. Different methods, like manual penetration tests or source code analysis, may be used to verify aspects such as input validation, depending on the application and requirements.

The Value of a Timeboxed Engagement

Building and operating any IT system securely is an ongoing process of building understanding, staying on top of the latest attacks and technology, and improving security posture over time. With that goal in mind, timeboxed engagements make sense and provide security value.

But only provided the reporting is accurate about what was covered. Identifying and remediating key issues (even without definitive coverage) and improving the shared understanding of a system leads to iteratively better security. An honest timeboxed assessment is a step forward.

The worst-case scenario is a timeboxed engagement that achieves poor coverage with a report that purports to be a complete thorough test of the system. This leads to a false sense of security, and can lead to the system receiving less security rigour over time.

Additionally, an engagement can be scoped and sized so tightly that the value disappears entirely. If a consultant cannot get through initial attack surface mapping before time runs out (P0), there is weak basis for any conclusions. I’m of the opinion that firms should not be selling engagements at that level of compression. If budget is genuinely limited to that degree, the more productive approach is usually in establishing internal processes and tooling: static analysis (SAST), dynamic analysis (DAST), dependency checking, basic cloud configuration and network auditing. These approaches provide ongoing, repeatable coverage that a single heavily compressed engagement cannot, and can generally be achieved cost effectively with Open Source tooling. This is particularly relevant for start ups.

Getting the foundations in order first provides a better return than a one-day assessment that cannot reasonably evaluate anything. This also means that if a penetration test happens in the future, the client can share the output of all of this tooling and the penetration tester can focus on finding impactful issues.

Summary

The question around testing is not whether testing will be time-limited, but whether that limitation is acknowledged and managed honestly.

The industry standards that define penetration testing methodology (NIST SP 800-115, OWASP WSTG, PCI DSS Penetration Testing Guidance, PTES, OSSTMM) don’t provide a solution to the prioritisation problem. The prioritisation framework described here is our attempt to fill that gap, and this article reflects our commitment to transparency around how we perform security analysis.

Transparency throughout this process is what makes a timeboxed engagement useful. A client who understands what was tested, what coverage was achieved, and what should happen next is in a better position than one who received a report that implied completeness it did not have.

The main variables clients can control are budget, scope, and shared context. Budget and testing focus reductions have a direct and predictable impact on coverage. Shared context like architecture documentation, source code access, tooling output, and robust technical discussions all improves coverage at no additional cost.

For practitioners, the uncertainty in timeboxed testing is a structural property of the problem, not a reflection of your individual capability. A well-structured assessment that is honest about its limits is better work than an overreached one that is not.

Have thoughts on this? Want to discuss how your next engagement could be better structured? Drop us a line at info@pulsesecurity.co.nz.

BONUS ROUND - Future articles on Penetration Testing and Security Review

This article is part of a Purpose and Execution of Penetration Testing series I have planned. This article, and the next ones in the series, are the result of Pulse Security’s experience performing engagements, innovating new ways to improve security assurance and (most importantly) shared discussions and collaboration between the Pulse team and our clients. The next article will be The Purpose of Penetration Testing, where we’ll discuss why one would want to perform security analysis of this kind and how it improves overall cyber-security posture.

There are a number of people I’d like to credit who have contributed to this thinking over time. Clients, colleagues and friends. You know who you are. This article isn’t just my work, it’s our work, and I feel very privileged to be able to share these thoughts with a wider audience.