Penetration Testing Frameworks

One of the biggest misconceptions about penetration testing is that it's all about using hacking tools. While tools like Nmap, Burp Suite, and Metasploit are important, they don't tell you what to test, when to test it, or how to document your findings. That's where many beginners struggle.

A successful penetration test is built around a process, not just a toolkit.

Imagine you're asked to perform a security assessment for a company. Before you touch a single system, you need to understand what's in scope, define the objectives, and establish the rules of engagement. As the assessment progresses, you'll gather information, identify vulnerabilities, validate potential risks, and document everything you discover. Without a structured approach, it's easy to overlook important assets or produce a report that's difficult for the client to act on.

Penetration testing frameworks were created to solve this problem. They provide a proven methodology that helps security professionals stay organized throughout an engagement while ensuring each stage of the assessment is completed in a logical order. Rather than reinventing the process every time, testers can rely on established standards that have been refined by the cybersecurity community over many years.

Using a framework also makes assessments more consistent. Whether you're working alone or as part of a larger team, following the same methodology helps ensure that important steps aren't skipped and that reports are easier for clients and other security professionals to understand.

In this article, we'll explore several of the most widely recognized penetration testing frameworks, including PTES, OSSTMM, the OWASP Web Security Testing Guide (WSTG), NIST SP 800–115, and ISSAF. We'll also look at MITRE ATT&CK and discuss how it complements traditional penetration testing by helping security teams better understand attacker behavior. By the end, you'll have a solid understanding of what each framework is designed for and when it makes the most sense to use it.

OSSTMM: Bringing Measurement to Penetration Testing:

There's a saying in engineering: if you can't measure it, you can't manage it. In most technical fields, that idea is just assumed. A bridge isn't considered safe because someone feels confident about it. It's tested, measured, and verified against standards.

Penetration testing hasn't always worked that way. A lot of reports still rely on descriptions, opinions, or loosely defined severity ratings that can change depending on who is performing the test.

The Open Source Security Testing Methodology Manual, or OSSTMM, was created to address that problem.

Developed by ISECOM, OSSTMM takes a more scientific approach to security testing. Instead of focusing on subjective interpretations of risk, it pushes for results that are measurable, repeatable, and consistent between testers. The idea is that two people testing the same environment should be able to reach similar conclusions if they follow the same process.

OSSTMM also treats security as more than just a network problem. It breaks it down into five different areas of interaction. Human security covers things like social engineering and how people can be manipulated. Physical security looks at real-world access such as badges, doors, and building entry points. Wireless security focuses on things like Wi-Fi, Bluetooth, and other radio-based communication. Telecommunications includes phone systems and VoIP infrastructure. Data networks cover traditional systems, applications, and network traffic.

The important takeaway here is that security failures do not always come from technical systems. A perfectly configured firewall does not matter much if someone can walk into a server room or trick an employee into resetting a password.

One of the key ideas in OSSTMM is turning security into something measurable. It introduces Risk Assessment Values, often referred to as RAVs. These values try to represent the relationship between how exposed a system is and how well it is protected. Instead of simply labeling something as high or medium risk, OSSTMM tries to express risk in a more quantifiable way.

In theory, this allows different testers to evaluate the same environment and arrive at similar results, which makes comparisons over time more meaningful.

The framework follows a structured four stage process.

The first stage is induction. This is where you figure out what actually exists. You identify systems, domains, and services, then confirm they belong to the organization. This might include checking DNS records, reviewing certificate data, and identifying exposed subdomains. By the end of this stage, you are no longer guessing. You have a verified list of assets.

The second stage is interaction. This is where you begin engaging with those systems to understand what is exposed. You might fingerprint services, map technologies, and observe which systems respond without authentication. The goal here is not exploitation but visibility into the attack surface.

The third stage is inquiry. This is where you start to determine what an attacker could actually do with what you found. If a vulnerability exists, this is where you confirm whether it leads to meaningful impact, such as unauthorized access to data or functionality.

The final stage is intervention. This stage focuses on response and validation. It involves checking how issues are handled, whether fixes actually reduce exposure, and whether controls are effective in practice. It is not just about finding problems but understanding how the system behaves when those problems are addressed.

OSSTMM also defines a specific reporting format called the Security Test Audit Report, which is designed to keep results consistent and comparable between different testers.

The strength of OSSTMM is its structure and focus on measurable outcomes. It brings a level of discipline that feels closer to engineering than traditional penetration testing. At the same time, it can feel heavy and less practical compared to more commonly used frameworks like OWASP or PTES, especially for day to day testing work.

It is not the easiest framework to pick up, but it is one of the most rigorous when it comes to structured and repeatable security assessment.

OWASP WSTG: Bringing Structure to Web Application Testing:

Web applications rarely have a single obvious starting point. Take something like an online retailer as an example. You're looking at user accounts, search functionality, shopping carts, payment processing, order history, and APIs all working together in one system.

At that point, the real question isn't "can I test this?" but "where do I begin without missing something important?"

It's easy to get stuck either repeating the same types of checks or overlooking entire areas of the application. That's exactly the problem the OWASP Web Security Testing Guide (WSTG) is designed to solve.

Most people recognize OWASP from the OWASP Top Ten, but the WSTG is much more detailed. It takes web application security testing and breaks it into a structured set of test cases that cover nearly every part of a modern application. Instead of relying on memory or improvisation, testers can follow a clear reference that outlines what to look for and how to approach each area.

The guide is organized into twelve main categories. These include things like authentication, session handling, input validation, authorization, configuration issues, cryptography, business logic flaws, client-side security, and API testing. Each category contains specific test cases with identifiers and guidance that help standardize the testing process across different applications and teams.

What makes this approach useful is that it doesn't treat all issues as equal. The focus is on risk and impact. Instead of just listing vulnerabilities, it helps testers prioritize what actually matters in a real-world environment.

One of the biggest differences between WSTG and many other approaches is that it isn't limited to the testing phase alone. It fits into the entire software development lifecycle.

In the early stages, security considerations start before any code is written. This is where requirements are defined, especially around compliance and data protection. For example, an application handling payments would need to align with standards like PCI DSS, and those requirements influence design decisions from the beginning.

During the design phase, the focus shifts to architecture and threat modeling. This is where teams start thinking about how different parts of the application could be abused. A payment flow, for example, might be identified as a high-risk area and designed with additional safeguards like input validation and rate limiting.

As development begins, security becomes more hands-on. Code reviews and walkthroughs help catch issues early, such as weaknesses in authentication logic or improper handling of password reset flows.

Once the application is deployed, testing becomes more practical and environment-focused. This is where penetration testing is used to validate that real-world configurations are secure, default credentials are removed, and no unintended endpoints are exposed.

Even after release, security doesn't stop. Applications evolve, and every update introduces the possibility of new issues. Because of this, testing needs to be repeated periodically, especially after major changes or feature additions.

The strength of the WSTG comes from how detailed it is. Instead of giving high-level advice, it provides specific test cases that can be followed step by step. This makes it especially useful for teams that want consistency across multiple testers or engagements.

It also stays relevant because it is maintained by a large security community. As web applications evolve into more complex systems like single-page applications and API-driven architectures, the guide continues to adapt.

The same level of detail that makes WSTG powerful can also make it difficult to fully apply in practice. Running every test case on every engagement is often unrealistic, especially under time or resource constraints.

It also requires judgment. If you treat it like a strict checklist, you risk missing the bigger picture of how the application actually behaves. The most effective testers use it as a reference rather than a script, combining structured testing with experience and intuition.

NIST SP 800–115: Security Testing With Structure and Accountability:

In some environments, especially government or regulated industries, penetration testing isn't just about finding vulnerabilities. It also has to stand up to auditors, compliance requirements, and formal review processes.

In those cases, informal reports or loosely defined risk ratings usually aren't enough. The expectation is a structured approach that can be repeated, reviewed, and defended if questioned later.

That's where NIST SP 800–115 comes in.

Published by the National Institute of Standards and Technology, this document provides a formal approach to security testing and assessment. Even though it was originally designed for federal agencies, it's now widely used in enterprise environments where consistency and accountability matter.

Unlike some frameworks that focus only on penetration testing, NIST SP 800–115 takes a broader view. It covers multiple types of security assessments, including documentation reviews, configuration analysis, vulnerability scanning, and penetration testing. In this model, penetration testing is just one tool in a larger assessment process rather than the entire focus.

The framework is built around three main goals. The first is identifying weaknesses across systems, networks, and applications. The second is validating whether existing security controls actually work as intended. The third is determining whether those weaknesses can realistically be exploited in a real-world scenario.

The testing approach is divided into three main phases, starting long before any active scanning or exploitation takes place.

The first phase is planning. This is where everything is defined in detail before any testing begins. Scope is clearly agreed upon, rules of engagement are established, and communication channels are set up. In regulated environments, this step is critical because it determines exactly what can and cannot be tested, when testing can occur, and how critical findings are escalated. The output of this phase is a formal test plan that all parties agree on.

The second phase is execution. This is where the actual security testing happens, but it isn't limited to just running tools or launching attacks. NIST breaks this phase into different types of activity.

Some parts involve reviewing existing documentation and configurations to identify weaknesses in policies or system design. Other parts focus on discovering live systems, open ports, and exposed services. From there, identified issues are validated to confirm they are real and not false positives. Finally, more advanced testing may simulate real attacks to understand the actual impact of a vulnerability.

The key idea here is progression. Testing moves from passive observation to active exploitation based on what the engagement requires. Not every assessment needs to go all the way to full exploitation if earlier stages already provide enough insight.

The final phase is post-testing. At this point, the focus shifts away from discovery and toward analysis. Findings are reviewed, severity is assigned, and results are translated into something actionable for the organization.

What makes this step important is the emphasis on clarity. It's not enough to say a vulnerability exists. The expectation is to explain what the issue is, what systems are affected, what the real-world impact could be, and how it can be fixed in practical terms.

One of the biggest strengths of this framework is its flexibility. Because it defines categories of testing rather than specific tools or techniques, it can be applied across very different environments, from traditional infrastructure to cloud systems and modern hybrid setups.

It also carries a lot of weight in government and regulated industries simply because it comes from NIST. That recognition makes it easier for organizations to justify their testing approach during audits or compliance reviews.

Another advantage is standardization. When multiple teams or vendors follow the same framework, results become easier to compare and trust.

Despite its strengths, NIST SP 800–115 is not a strict requirement. It is guidance rather than enforcement. Unlike standards that mandate testing schedules or penalties, it doesn't force organizations to follow a specific cadence or checklist.

It also assumes a fairly high level of skill from the people performing the assessment. Since it spans everything from documentation review to active exploitation, testers need a broad range of experience to apply it effectively.

In practice, it works best in environments where structure and accountability are important, but flexibility is still needed in how testing is actually carried out.

PTES: The Framework That Mirrors Real Penetration Testing Workflows:

After looking at frameworks like OSSTMM, OWASP WSTG, and NIST SP 800–115, one thing becomes clear. Most of them focus on either measurement, coverage, or structured assessment techniques. But there's still an important question that isn't always directly answered.

What does a real penetration test actually look like from start to finish?

That's where PTES, the Penetration Testing Execution Standard, stands out.

PTES was created by experienced practitioners who wanted to define what a full engagement actually looks like in practice. Instead of focusing only on what should be tested or how results should be measured, it focuses on how a penetration test unfolds in the real world, from the first conversation with a client to the final report.

This makes it one of the most practical frameworks, especially for people trying to understand how all the pieces of a pentest fit together.

PTES is built around seven phases that reflect the natural flow of an engagement.

The first stage is pre-engagement. This is everything that happens before testing begins. Scope is defined, expectations are set, and rules are agreed upon. You determine what systems are in scope, what time windows are allowed for testing, who the points of contact are, and what actions require immediate escalation.

This stage is often underestimated, but in practice it is one of the most important parts of the entire engagement. Clear scoping prevents legal issues, reduces confusion, and ensures both sides understand exactly what is being tested.

Next comes intelligence gathering. Once the engagement is approved, the focus shifts to collecting information about the target environment. This includes both passive and active techniques.

Passive gathering might involve identifying employee information, public-facing infrastructure, or technology hints exposed through job postings or external metadata. Active gathering involves interacting with systems in scope to understand what is actually running and exposed.

The goal here is simple. Build a clear picture of the environment before attempting any exploitation.

After that is threat modeling. At this stage, the focus moves from raw information to understanding risk and attack paths. Not every system is equally important, and not every vulnerability leads to meaningful impact.

Threat modeling helps identify what actually matters. For example, an externally exposed application might lead directly to sensitive data, while an internal system might only become relevant if initial access is achieved elsewhere. This step helps prioritize effort and avoid random testing.

Then comes vulnerability analysis. Once the environment is understood, the next step is identifying weaknesses that could be used to achieve the attack paths identified earlier.

This includes both automated scanning and manual validation. The important part here is not just finding potential issues, but confirming which ones are real and exploitable. Many findings from automated tools never survive manual verification.

Exploitation follows next. This is where confirmed vulnerabilities are tested in a controlled and intentional way. The objective is not simply to gain access for its own sake, but to demonstrate real-world impact.

For example, successfully exploiting a vulnerable service might lead to system access, which can then be used to show how far an attacker could realistically go within the environment.

PTES emphasizes that exploitation should always tie back to business impact, not just technical achievement.

After that comes post-exploitation. Once access is obtained, the focus shifts to understanding what that access actually means. This is where the real value of a penetration test is often demonstrated.

It might involve accessing sensitive data, moving laterally within a network, or showing how credentials can be reused across systems. The goal is to translate technical access into real business risk that decision-makers can understand.

Finally, there is reporting. The findings are documented in a way that serves two audiences.

Executives need a clear explanation of what the risks are and why they matter. Technical teams need detailed steps, evidence, and remediation guidance.

A good report connects both sides without overcomplicating either one.

PTES is one of the most practical frameworks for understanding how penetration tests actually flow in real environments. It's especially useful for newer testers because it connects all the stages of an engagement into a single, logical process.

The main limitation is that it hasn't been updated in quite some time, so some of the technical references are outdated. However, the structure itself still holds up well and reflects how modern penetration testing engagements are commonly conducted.

It doesn't focus on strict measurement or deep technical coverage like other frameworks. Instead, it focuses on workflow, which is often what people struggle with most when starting out.

ISSAF: An Older Framework That Still Teaches How Attackers Think:

Some frameworks age out of active use, but their ideas still stay relevant. In cybersecurity, tools and exploits change constantly, but structured thinking about how attacks unfold tends to remain surprisingly consistent.

ISSAF, the Information Systems Security Assessment Framework, is a good example of that.

It was developed by the Open Information Systems Security Group and was last formally updated around 2006. That means it's no longer maintained and definitely not something you would rely on for modern tooling or up-to-date exploitation techniques. In fact, most of the original documentation is now only available through archived sources.

Even so, it's still worth studying.

The reason is simple. ISSAF describes security testing in a way that closely mirrors how real attackers move through an environment. Instead of focusing only on individual tests or tools, it shows a progression of how systems are explored, compromised, and expanded upon. That kind of structure doesn't really go out of date.

It also helps that ISSAF covers a wide range of areas including networks, operating systems, applications, databases, and even social engineering. The approach is risk-driven, meaning attention is focused on issues that actually lead to meaningful impact rather than minor findings.

ISSAF is divided into three main stages, with a more detailed progression inside the assessment phase.

The first stage is planning and preparation. This is where everything is defined before any testing begins. Scope is agreed upon, communication channels are established, and limitations are made clear. In practice, this is where you determine what systems can be tested, what cannot be touched, and how issues will be escalated if something critical is discovered. It also includes aligning on expectations so there are no surprises once testing starts.

The second stage is the actual assessment work, and this is where ISSAF's structure becomes more detailed.

It starts with information gathering. This is where publicly available data is collected to build an understanding of the target environment. That might include DNS records, employee information, exposed services, or technical details found in job postings or documentation.

Next is network mapping, where the structure of the environment starts to take shape. Systems are identified, relationships between services are discovered, and the external and internal attack surface becomes clearer.

After that comes vulnerability identification. This is where weaknesses are discovered across the environment, whether through scanning or manual analysis. At this point, the focus is still on discovery rather than exploitation.

Once vulnerabilities are identified, testing moves into exploitation. This is where selected weaknesses are validated to understand their real-world impact. Successful exploitation typically provides an initial foothold in the environment.

From there, the focus shifts to privilege escalation and access expansion. The goal is to move from limited access to more powerful accounts or systems, demonstrating how far a compromise could realistically go.

The next step is enumeration. At this point, access is used to gather additional information from within the environment. That might include credentials, configuration data, source code, or internal documentation that was not previously visible.

After that comes lateral movement. Instead of staying on a single system, the assessment expands into other parts of the network using newly discovered credentials or trust relationships between systems.

Persistence is then considered. This is where the focus shifts to understanding how an attacker could maintain access over time. In a real engagement, this is typically documented rather than implemented, but it shows whether an environment could be re-entered after remediation or reboot.

Finally, there is covering tracks. This involves analyzing how activity would appear in logs and whether the environment has enough visibility to detect or investigate malicious behavior. It highlights gaps in logging and monitoring that could allow an attacker to operate unnoticed.

What stands out in this progression is how naturally each step builds on the previous one. It reflects how real attacks evolve over time rather than treating each test as an isolated task.

The final stage of ISSAF is reporting and cleanup. Findings are organized based on impact, with emphasis placed on issues that led to meaningful compromise. Cleanup ensures that no test artifacts remain behind and that the environment is returned to its original state.

ISSAF's main contribution is not its tooling or technical instructions. Those are outdated and no longer applicable in modern environments. Its value comes from the way it models attacker behavior in a structured, sequential way.

That said, its age is also its biggest limitation. There is no active maintenance, no updates for modern technologies, and no community-driven evolution of the framework. Because of that, it should not be used as a technical guide for current engagements.

Instead, it works best as a conceptual model for understanding how attacks progress through an environment. For up-to-date techniques and tools, frameworks like PTES or OWASP WSTG, along with current vendor documentation, are far more appropriate.

MITRE ATT&CK: Connecting Penetration Testing to Real-World Attacks:

Up to this point, most penetration testing frameworks focus on how you conduct an engagement. They define the process: how to scope it, how to move through different phases, and how to present the results.

But there's a different question that often comes up once the report is finished.

How does what you found actually compare to what real attackers are doing in the wild?

A report might describe phishing as an initial access vector, credential theft during post-exploitation, and lateral movement across internal systems. While that information is useful, it doesn't always explain how those actions relate to real-world adversary behavior seen in actual incidents.

This is the gap that MITRE ATT&CK fills.

ATT&CK, which stands for Adversarial Tactics, Techniques, and Common Knowledge, is not a penetration testing framework. Instead, it is a knowledge base built from observed attacker behavior. It documents how real threat actors operate, based on analysis of real incidents across different environments and industries.

Rather than telling you how to perform a test, it helps you describe what you observed using a shared language that reflects how actual attacks unfold.

At the center of ATT&CK is the matrix.

The matrix organizes attacker behavior into two main layers. At the top level are tactics, which describe the goal behind an action. These represent the "why" in an attack chain, such as gaining initial access, maintaining persistence, escalating privileges, or exfiltrating data.

Within each tactic are techniques, which describe the "how." These are the specific methods used to achieve each objective. For example, gaining initial access might involve phishing, exploiting a public-facing application, or using valid accounts. Each of these techniques can be further broken down into more specific sub-techniques, such as different variations of phishing or credential use.

What makes ATT&CK particularly useful is that it doesn't stop at classification. Each technique is backed by real-world examples, detection guidance, and mitigation strategies. This turns it into something more practical than a simple taxonomy. It becomes a reference that security teams can actively use to improve detection and response.

The important distinction is that ATT&CK is not designed to replace penetration testing frameworks. It does not define how to scope an engagement or how to structure a report. Instead, it adds context to the results of those engagements.

A useful way to think about it is the difference between a procedure and a reference model. A penetration testing framework like PTES defines the process you follow during an assessment. ATT&CK, on the other hand, provides a standardized way to describe what you found during that process.

One tells you how to perform the test. The other helps you explain what the test revealed in terms of real attacker behavior.

This becomes especially useful when mapping findings from a penetration test to ATT&CK techniques. For example, phishing used to compromise a workstation can be associated with spearphishing techniques under initial access. Exploiting a vulnerable public-facing application maps to known exploitation techniques. Credential dumping aligns with credential access techniques, while lateral movement and data access map to their respective categories in the matrix.

When a penetration test report includes these mappings, the output becomes more meaningful to security teams. Instead of reading isolated vulnerabilities, they can connect findings to known adversary behaviors. This allows them to think in terms of detection and response rather than just patching individual issues.

It shifts the conversation from fixing one vulnerability at a time to understanding whether the organization can detect and respond to entire classes of attack behavior.

The real strength of ATT&CK is that it creates a shared language between different areas of security. Penetration testers, threat hunters, detection engineers, and incident responders can all refer to the same techniques and understand exactly what is being discussed.

That said, the framework is extensive. The enterprise matrix alone contains hundreds of techniques, and becoming comfortable with it takes time. It is not something most people memorize quickly. Instead, it becomes more useful the more it is applied in real scenarios.

For penetration testers, the key takeaway is simple. ATT&CK does not replace existing frameworks. It enhances them by providing a way to connect technical findings to real-world adversary behavior.

Other Frameworks You'll Run Into in Real Penetration Testing Work:

So far, most of the frameworks covered have been fairly general-purpose. OSSTMM focuses on measurement, OWASP WSTG on web application testing, NIST on structured security assessments, PTES on real-world engagement flow, ISSAF on attacker progression, and MITRE ATT&CK on adversary behavior.

Together, those form the core set of knowledge most penetration testers are expected to understand at a foundational level.

But once you start working across different industries, you quickly realize that not every engagement fits neatly into those categories. Depending on what you're testing, you may run into additional frameworks that are far more specialized.

Most of these aren't about replacing what you already know. They exist to cover specific environments, compliance requirements, or technology stacks that general frameworks don't fully address.

WASC Threat Classification is one of the earlier attempts to organize web application threats in a structured way. It categorizes issues like authentication weaknesses, information disclosure, and misuse of application functionality. While it played an important role in shaping how web vulnerabilities were discussed years ago, it has mostly been replaced in practice by OWASP resources like the Top Ten and the WSTG. You'll usually only see WASC referenced in older documentation or legacy security material.

The Cloud Security Alliance Cloud Controls Matrix is a different kind of framework altogether. Instead of focusing on testing methodology, it focuses on security controls for cloud environments. It maps out what good security should look like across areas like identity management, data protection, and infrastructure security, and aligns those controls with standards such as ISO 27001 and NIST. This is not something you use to run a penetration test directly. It shows up more in audits, cloud security reviews, and compliance-driven assessments where the goal is to evaluate whether cloud environments meet certain security expectations.

For mobile applications, OWASP provides the Mobile Application Security Testing Guide. This is essentially the mobile counterpart to the web-focused WSTG. It covers Android and iOS applications in detail, including areas like local data storage, encryption, network communication, and how the app interacts with the underlying operating system. If you're testing anything like a banking app or a healthcare mobile application, this becomes one of the main references you work from, often alongside the Mobile Application Security Verification Standard which defines the security requirements being tested.

In environments that handle payment card data, PCI DSS introduces its own set of penetration testing requirements. These are not optional guidelines in the traditional sense. They are part of a regulatory standard that organizations must follow if they store, process, or transmit cardholder information. The requirements include regular penetration testing, testing after significant infrastructure changes, and validating that network segmentation is working as intended. For testers, this means PCI DSS doesn't just influence how you test, it often dictates the scope and timing of the entire engagement.

Then there is CBEST, which is used primarily in the UK financial sector. Unlike traditional frameworks, CBEST is built around realistic threat scenarios. It starts with threat intelligence to understand what kinds of attackers are most relevant to a specific financial institution, and then uses that information to shape the penetration test itself. The goal is not just to find vulnerabilities, but to simulate how real-world threat actors would approach that organization specifically. Because of this, CBEST engagements tend to feel closer to red team exercises than standard penetration tests.

If you look at these frameworks side by side, the differences become clearer.

WASC is mostly historical at this point and useful for understanding how web vulnerability classification evolved.

CSA CCM is focused on cloud security governance rather than hands-on testing.

OWASP MASTG is a practical testing guide for mobile applications.

PCI DSS is a regulatory requirement that directly shapes how penetration tests must be performed in payment environments.

CBEST is a threat-driven model used in regulated financial sectors, especially in the UK.

The main takeaway from all of this is that framework choice is rarely arbitrary. It depends heavily on context. The type of system, the industry involved, and the regulatory environment all influence what you're expected to follow.

A penetration tester working in financial services might deal with PCI DSS requirements on every engagement. Someone testing mobile applications will rely heavily on OWASP guidance. In cloud environments, CSA controls may come into play during security reviews.

Understanding that landscape is just as important as knowing how to execute the tests themselves. It helps you recognize not just how to test something, but what standard your work is expected to align with once you're done.