Payment security is no longer a “once-a-year audit” problem. It’s an always-on risk management discipline—because attackers don’t wait for assessment season, and customers don’t forgive preventable data exposure. 

That is exactly why the PCI Data Security Standard (PCI DSS) keeps evolving: to set a baseline of technical and operational controls that protect account data across modern environments, including cloud, ecommerce, APIs, mobile, and third-party service providers.

As of today, PCI DSS v4.0.1 is the current active version of the standard supported by the PCI Security Standards Council (PCI SSC), and it is a limited revision that clarifies intent and guidance without adding or removing requirements. 

Many of the “future-dated” items introduced in v4.x became mandatory after March 31, 2025—meaning they are no longer optional best practices; they are part of what assessors and internal teams must validate now.

This PCI DSS requirements overview is designed for merchants, service providers, and payment-adjacent businesses that store, process, or transmit cardholder data (CHD) or sensitive authentication data (SAD), or that can impact the security of the cardholder data environment (CDE). 

You’ll learn what the PCI DSS requirements are, how to scope them correctly, how validation works, what’s changed in v4.x, and how to build a compliance program that is both audit-ready and breach-resistant.

Throughout this guide, you’ll see the phrase PCI DSS requirements often—because for ranking, clarity, and training value, it’s important to anchor the discussion on the actual control expectations, not just high-level slogans. 

Use this article as a living reference, and revisit it when you change payment flows, add vendors, migrate infrastructure, or launch new channels.

What PCI DSS Is and Who Must Follow PCI DSS Requirements

PCI DSS is a global baseline standard designed to protect account data by defining minimum security controls for any entity involved in storing, processing, or transmitting payment card data. The PCI DSS requirements apply broadly: from a small retailer using a hosted checkout page to large service providers operating complex multi-tenant platforms. 

Even if you outsource payment processing, you may still have PCI DSS requirements—because outsourcing does not outsource accountability. The standard explicitly addresses how organizations must manage relationships with third-party service providers (TPSPs), and v4.0.1 includes clarifications around customer/TPSP responsibilities and applicability notes.

A practical way to understand applicability is to map your “card data touchpoints.” If your systems store cardholder data (even temporarily), process card payments, transmit cardholder data across networks, or can impact the security of those functions, PCI DSS requirements are likely in scope. 

Common examples include ecommerce payment pages, scripts loaded in checkout, call-center payment workflows, databases with PAN, logs, support tools with screen-sharing, and administrative access paths into the CDE.

Importantly, PCI DSS requirements are not only about technology. They also cover policies, training, governance, incident response, vendor management, vulnerability management, and access control discipline. 

PCI DSS v4.x places increased emphasis on continuous security and risk-based decisioning, so “we passed last year” is not a meaningful security argument anymore—especially in fast-changing environments with frequent deployments and vendor integrations.

If you’re building a compliance program in a regulated marketplace (for example, businesses with higher fraud pressure or reputational sensitivity), treating PCI DSS requirements as a security operating system—rather than a checklist—reduces both assessment pain and real-world risk.

PCI DSS v4.0.1 vs v4.0: What Changed, What Didn’t, and Why It Matters

Many teams ask, “Do we have to redo everything because of v4.0.1?” The useful answer: v4.0.1 is not a new standard with new controls—it is a limited revision that corrects formatting/typographical issues and clarifies intent and applicability across several areas. 

PCI SSC states there are no additional or deleted requirements in v4.0.1. That matters because it refocuses organizations on execution quality, evidence quality, and scoping discipline—not on chasing brand-new control categories.

At the same time, the clarifications are not trivial. For example, v4.0.1 includes clarifications around patching language (re-aligning the “within 30 days” expectation to critical vulnerabilities), payment page script applicability notes, and MFA applicability for users authenticated with phishing-resistant factors. 

These clarifications influence how assessors interpret PCI DSS requirements and how you document compensating control logic or customized approach evidence.

Another major practical point: PCI DSS v4.0 was set to retire on December 31, 2024, after which v4.0.1 became the only active version supported by PCI SSC. 

In other words, if your policies, control matrices, and ROC/SAQ evidence still reference v3.2.1 or older phrasing, you’re not just “behind”—you’re creating preventable ambiguity during validation and increasing the chance of remediation cycles.

Finally, v4.x introduces more explicit support for a customized approach, along with resources and guidance (including targeted risk analysis support materials). That doesn’t mean “do whatever you want.” 

It means: meet the intent of PCI DSS requirements with measurable outcomes, strong testing procedures, and defensible evidence.

PCI DSS Scoping: Defining the Cardholder Data Environment Without Over-Scoping

Scoping is where PCI programs succeed or fail. Get it right, and PCI DSS requirements become manageable and measurable. Get it wrong, and you either (a) over-scope, ballooning cost and complexity, or (b) under-scope, creating blind spots that attackers love—and assessors eventually uncover.

The cardholder data environment (CDE) includes people, processes, and technologies that store, process, or transmit cardholder data or sensitive authentication data. The scope also includes systems connected to or capable of impacting the CDE. 

That “impact” concept is why shared admin domains, monitoring systems, jump hosts, CI/CD pipelines, and endpoint management tools can become in scope if they can alter CDE configurations or security controls.

A strong scoping process typically includes:

1. data-flow diagrams for each payment channel,
2. an inventory of in-scope assets (including cloud services),
3. network diagrams showing segmentation boundaries,
4. documented segmentation controls and validation testing, and
5. a clear responsibility matrix across internal teams and vendors.

PCI DSS requirements don’t require you to store PAN; in many cases the safest and easiest path is to redesign flows so you don’t store cardholder data at all. Tokenization, hosted payment fields, and redirect-based checkout can dramatically shrink scope. 

But you still need to validate what remains—especially payment page integrity, access paths, and vendor touchpoints. PCI SSC has published scoping and segmentation guidance resources for modern architectures through its v4.x resource hub.

In real-world assessments, scoping failures often come from “shadow” payment processes: emailed card details, screenshots, chat transcripts, call recordings, or misconfigured logging. Treat scoping as a recurring operational control, not a one-time diagram exercise, and your PCI DSS requirements will stay aligned to reality.

Requirement 1: Network Security Controls That Enforce Strong Boundaries

PCI DSS requirements begin with controlling how traffic flows, because payment environments are high-value targets and lateral movement is a common breach pattern. 

Requirement 1 focuses on network security controls—the modern evolution of “firewalls and routers”—to enforce segmentation, restrict inbound and outbound traffic, and limit exposure of the CDE.

A strong program starts with documented network standards: approved services/ports, secure configuration baselines, and clear ownership of rule changes. 

If you use cloud security groups, WAF policies, container network policies, or zero-trust gateways, these can all be part of your network security control story—as long as you can prove they enforce the PCI DSS requirements consistently.

Segmentation is not a buzzword; it’s a cost-control strategy. When done correctly, segmentation reduces the number of systems subject to PCI DSS requirements. But segmentation must be validated. 

That means you need evidence that non-CDE systems cannot reach CDE systems through allowed paths, misconfigured VPNs, peered networks, or shared administrative tooling.

In practice, teams should treat Requirement 1 as a set of repeatable processes: rule review cadence, change management records, automated policy-as-code where possible, and continuous monitoring for drift. 

If you only review firewall rules once per year, you’ll accumulate risky exceptions and “temporary” ports that never close.

Future-looking prediction: over the next few years, more organizations will satisfy Requirement 1 evidence expectations through continuous control monitoring (CCM) platforms, cloud posture management, and automated network policy verification—because dynamic infrastructure makes manual rulebooks unreliable. 

PCI DSS requirements will increasingly be proven through telemetry and automated attestations, not static screenshots.

Requirement 2: Secure Configurations and Hardening as a Baseline, Not a Project

Default configurations are designed for convenience, not security. Requirement 2 of PCI DSS requirements is about building and maintaining secure configurations for system components: servers, endpoints, databases, network devices, containers, and cloud resources. 

This requirement is where many organizations create technical debt—because they harden once, then drift.

Hardening should be standardized: secure build images, CIS-aligned baselines where appropriate, configuration management, and controlled administrative access. 

You also need to address unnecessary services, default accounts, vendor-supplied passwords, and insecure protocols. In cloud, this translates to disabling public storage where not needed, enforcing private endpoints, restricting metadata exposure, and using least-privilege IAM roles.

A mature Requirement 2 program connects three disciplines:

• baseline definition (what “secure” looks like),
• deployment enforcement (how systems get built), and
• drift detection (how you catch changes).

Evidence should not rely on one-off manual checks. The best PCI DSS requirements evidence for Requirement 2 includes: version-controlled baseline documents, automation outputs, exception approvals, and change records tying configuration updates to risk or vulnerability drivers.

Requirement 3: Protect Stored Account Data With Strong Cryptography and Data Minimization

Requirement 3 is where PCI DSS requirements get very specific: protect stored account data, especially the PAN. The most effective strategy is don’t store it. If business requirements truly demand storage, then you must implement strong cryptography, key management discipline, and clear data retention rules.

This requirement covers: rendering PAN unreadable where stored, limiting data retention, protecting keys, and ensuring sensitive authentication data is not stored after authorization. It also includes clarity for organizations using keyed cryptographic hashes to render PAN unreadable, and v4.0.1 includes clarifications and applicability notes in this area.

A strong Requirement 3 posture typically includes tokenization, format-preserving encryption (when justified), and hardened key management (HSMs or cloud KMS with strict IAM, rotation, and separation of duties). 

You need documented retention schedules and technical enforcement—because “policy says delete after X days” is not proof.

From an operational standpoint, the hardest part is data discovery. PAN can leak into logs, analytics, debugging traces, customer support systems, and backups. Build automated scans to detect PAN patterns in storage and logs, then remediate by masking, filtering, or redesigning.

Requirement 4: Encrypt Transmission of Cardholder Data Across Open, Public Networks

Requirement 4 addresses a simple truth: data in motion is vulnerable—especially across open networks and misconfigured internal paths. PCI DSS requirements here focus on using strong cryptography and secure protocols to protect CHD transmissions.

Practically, this means enforcing TLS with modern configurations, disabling weak ciphers, and ensuring certificates are managed properly. 

It also means understanding where data actually travels: between browsers and web servers, between application tiers, to third-party services, across VPNs, and within cloud service integrations. “Internal network” is not automatically “trusted,” especially with remote work, hybrid infrastructure, and vendor connectivity.

A robust approach includes:

• TLS policy baselines and automated scanning,
• certificate lifecycle management (rotation, revocation readiness),
• secure API gateway controls, and
• strict controls around file transfers, emails, and messaging systems that might carry CHD.

Requirement 4 also intersects with ecommerce script integrity and third-party services. If your checkout page pulls scripts from multiple sources, your protection story must cover both encryption and integrity. Attackers frequently target the browser side because it bypasses your backend encryption entirely.

Requirement 5: Protect Systems and Networks From Malware—Including Modern Threats

Requirement 5 is not just “install antivirus.” PCI DSS requirements demand that organizations protect systems against malware using mechanisms appropriate to the risk and technology involved. That includes endpoints, servers, virtual desktops, and—depending on architecture—containers and workloads.

Modern malware defenses typically include endpoint detection and response (EDR), anti-malware tooling, behavioral detection, and strong operational processes: alert triage, response playbooks, and exception handling. 

If you claim “not applicable” because a system can’t run traditional anti-malware, you still need alternative controls and risk-based justification.

The most common program weakness is not tooling; it’s operations. If your security alerts aren’t reviewed consistently, or you lack evidence of response actions, assessors may view your control as ineffective. Evidence should show: policy, deployment coverage, update status, alert review cadence, and action tracking.

Requirement 5 also intersects with phishing resistance and credential theft. While that’s more directly covered under access controls, malware and credential compromise are tightly linked in real incidents.

Requirement 6: Secure Systems and Software Through Vulnerability and Patch Management

Requirement 6 is where PCI DSS requirements meet the reality of continuous delivery. You must develop and maintain secure systems and software, remediate vulnerabilities, and apply patches appropriately. PCI SSC clarified in v4.0.1 that installing patches/updates within 30 days applies specifically to critical vulnerabilities, aligning language back toward earlier phrasing.

A strong Requirement 6 program includes:

• secure SDLC practices (requirements, design reviews, threat modeling),
• code review and testing processes,
• dependency management (SCA),
• vulnerability scanning and triage, and
• patch SLAs tied to severity and exploitability.

The highest-risk failure mode is “we found it, but we didn’t fix it fast.” Vulnerability backlogs grow silently, then explode during assessment—or worse, during a breach. Build a remediation pipeline that ties vulnerabilities to owners, deadlines, and verification steps. Make exceptions rare, documented, time-bound, and approved at the right level.

Requirement 6 also touches payment page script management. If your ecommerce environment uses scripts that can affect cardholder data entry, you must control and monitor them. v4.0.1 adds applicability notes clarifying how those requirements apply.

Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need

Requirement 7 of PCI DSS requirements centers on least privilege: access is granted only when needed, scoped to job function, and reviewed regularly. This is one of the strongest breach-prevention controls when implemented correctly, because many incidents are “valid credentials doing dangerous things.”

To meet Requirement 7, you need a consistent access model: role-based access control (RBAC), attribute-based controls where appropriate, and separation of duties (especially for key management, security administration, and production changes). 

Access must be approved, documented, and periodically reviewed. It’s not enough to say “managers approve access in tickets”—you also need to show that the granted privileges match the request and that reviews actually lead to removals.

Requirement 7 becomes more complex with cloud and SaaS. Permissions can spread across IAM roles, resource policies, API keys, service accounts, and third-party integrations. The best practice is to centralize identity, enforce least privilege templates, and use access analytics to detect “permission creep.”

Requirement 8: Identify Users and Authenticate Access, With MFA and Phishing Resistance

Requirement 8 is about ensuring every user is uniquely identified and strongly authenticated before accessing system components—especially the CDE. PCI DSS requirements here include multi-factor authentication (MFA) expectations and strong credential practices.

v4.0.1 includes an applicability note clarifying that MFA for all (non-administrative) access into the CDE does not apply to user accounts authenticated only with phishing-resistant authentication factors. 

This is a meaningful direction: it recognizes that not all MFA is equal. Push-based approvals can be phished; cryptographic, phishing-resistant factors raise the bar.

A practical Requirement 8 program includes:

• centralized identity (SSO) where possible,
• MFA for administrative access and remote access,
• strict password/credential policies (or passwordless),
• secure management of service accounts, and
• session management and lockout policies.

Evidence must show not just policy, but enforcement: configuration screenshots, identity provider settings, access logs, and a joiner/mover/leaver process proving accounts are removed quickly. 

Shared accounts are a recurring PCI DSS requirements failure—especially in support teams and legacy systems. Where shared accounts are technically unavoidable, you need strict compensating controls and strong traceability.

Requirement 9: Restrict Physical Access to Cardholder Data and Systems

Even in a cloud-forward world, physical security remains part of PCI DSS requirements. Requirement 9 focuses on restricting physical access to cardholder data and systems in scope. This includes data centers (often handled by cloud providers), offices, retail locations, call centers, and any environment where systems that can access the CDE exist.

For many organizations, this requirement is met through a combination of provider attestations (for hosted infrastructure) and internal controls (for corporate offices). You need visitor logs, badge controls, secure storage for media, device handling procedures, and clear processes for protecting physical documents that may contain account data.

Call centers deserve special attention. Payment information can appear in paper notes, audio recordings, or screen captures. If your business takes card payments over the phone, you must ensure that physical and operational processes prevent leakage—clean desk policy, restricted printing, locked storage, and clear destruction procedures.

Requirement 10: Log and Monitor All Access to System Components and Cardholder Data

Requirement 10 is the detective control backbone of PCI DSS requirements. If you can’t answer “who did what, when, and from where,” you can’t investigate incidents, validate controls, or detect misuse.

A strong Requirement 10 program defines what must be logged (authentication events, privilege changes, access to PAN, administrative actions, security configuration changes), where logs go (centralized SIEM/log platform), how long they’re retained, and how they’re reviewed. You also need time synchronization so events can be correlated accurately.

The biggest failure is collecting logs without using them. PCI DSS requirements expect monitoring and review processes—daily/regular review of key events, alerting on suspicious behavior, and documented responses. If alerts trigger but no one can show triage records, your monitoring control may be considered ineffective.

Logging is also essential for third-party accountability. If vendors can access in-scope systems, you need logs that show vendor activity, not just internal user actions. Combine logs with network telemetry and endpoint signals for better visibility.

Requirement 11: Test Security of Systems and Networks Through Scanning and Penetration Testing

Requirement 11 is about proving that your defenses hold up, not just that they exist on paper. PCI DSS requirements include vulnerability scanning (internal and external where applicable), penetration testing, intrusion detection/prevention where relevant, and change-detection mechanisms.

External vulnerability scanning often involves Approved Scanning Vendors (ASVs), and PCI SSC publishes resources and guidance through its document library and resource hub. But scanning alone is not enough. You must remediate findings, validate remediation, and maintain a cadence that matches your risk profile.

Penetration testing must be planned, scoped correctly, and performed by qualified resources. It should reflect real payment attack paths: segmentation bypass, credential compromise, web application flaws, script injection in ecommerce, and misconfigurations in cloud IAM. If you have segmentation, you need segmentation testing to prove it works as intended.

Change detection is increasingly critical for modern ecommerce. If payment pages are updated frequently, you need mechanisms that detect unauthorized modifications. That connects directly to payment page integrity risks and modern skimming attacks.

Requirement 12: Support Information Security With Strong Policies, Risk Management, and Vendor Governance

Requirement 12 is the governance heart of PCI DSS requirements. It covers security policies, risk assessments, training, incident response, and third-party management. This requirement is often underestimated because it feels “administrative,” but in assessments it’s a common source of gaps—especially around vendor responsibility and documented accountability.

v4.x also introduced stronger emphasis on risk-based decisioning, including targeted risk analysis (TRA) concepts supported by PCI SSC guidance materials. 

TRA is not a generic enterprise risk assessment. It’s meant to justify frequencies and approaches for certain control activities when the standard allows risk-based determination. Done correctly, it creates flexibility; done poorly, it becomes a red flag.

Vendor governance is essential. If you use third-party service providers that can affect payment security (hosting, support, ecommerce scripts, monitoring, WAF/CDN, managed services), you need due diligence, contracts, documented responsibilities, and ongoing monitoring. PCI DSS v4.0.1 clarifies applicability notes about relationships between customers and TPSPs.

Incident response is another centerpiece: define what constitutes an incident, roles and escalation, forensic readiness, customer notification planning aligned with applicable laws/regulations, and post-incident lessons learned. Teams should run tabletop exercises and retain evidence of those exercises.

Validation, SAQs, ROC, and Evidence: How Organizations Prove PCI DSS Requirements Are Met

Meeting PCI DSS requirements is only half the work. The other half is proving it—clearly, consistently, and with evidence that matches testing procedures. Validation methods depend on your role (merchant vs service provider), transaction volume, and environment complexity.

Common validation paths include:

• SAQ (Self-Assessment Questionnaire): for eligible environments with simpler payment channels and constraints.
• ROC (Report on Compliance): typically required for larger or more complex environments, completed by a Qualified Security Assessor (QSA).
• AOC (Attestation of Compliance): formal statement of compliance status.

Evidence quality matters. “Policy exists” is not “control operates.” Strong evidence includes system configuration exports, identity provider settings, logs showing reviews, ticket records showing approvals, scan reports with remediation, and diagrams that match what’s deployed. Where automation exists, exportable reports from tools can reduce manual burden.

A key modern challenge is shared responsibility. Cloud providers, hosted payment providers, and managed security vendors each own pieces of the control stack. 

Your job is to map PCI DSS requirements to responsibility owners and ensure you can obtain dependable evidence. PCI SSC’s v4.x resource hub centralizes many supporting documents and updates that help teams interpret expectations and keep templates current.

Common PCI DSS Requirements Pitfalls and How to Avoid Audit Surprises

Most PCI failures aren’t caused by ignorance of the PCI DSS requirements. They’re caused by operational drift, unclear scope, and weak evidence practices. A few pitfalls appear repeatedly across organizations of every size.

One frequent issue is underestimating payment page risk. Even if you don’t store PAN, client-side attacks can skim data before it reaches your server. 

If your checkout page includes third-party scripts, tag managers, or marketing pixels, you must control and monitor them. v4.0.1 specifically notes applicability clarifications for managing payment page scripts.

Another issue is access sprawl: too many admins, stale accounts, shared logins, and unclear separation of duties. You can “have MFA” and still fail PCI DSS requirements if you can’t show consistent enforcement and review outcomes.

Third, teams often treat vulnerability management as a tool problem instead of a workflow problem. Scan results without timely remediation and verification create repeat findings and risk exposure. Clarified patching language in v4.0.1 helps, but it doesn’t remove the need for disciplined prioritization and ownership.

Finally, organizations get surprised by vendor dependencies. If a vendor won’t provide documentation or proof of their role, you may not be able to complete your compliance story. Build vendor evidence requirements into contracts and onboarding.

FAQs

Q.1: Are all “future-dated” PCI DSS requirements mandatory now?

Answer: Yes. The standard introduced certain requirements as future-dated to allow a transition period, but PCI SSC has stated that the effective date for these new requirements was not changed by the v4.0.1 revision. 

Many industry timelines and assessor guidance align around the March 31, 2025 milestone for future-dated requirements becoming mandatory, which means organizations operating today should treat them as baseline expectations, not optional enhancements.

What this means operationally is simple: if your compliance program still labels some v4.x items as “best practice,” you should revisit those decisions. 

In evidence terms, assessors will expect either implementation proof or a defensible explanation of how you meet the intent through alternative controls (for example, a customized approach with strong testing procedures and outcomes). The safest strategy is to implement the controls as written unless you have a compelling reason not to.

Q.2: If we outsource payments, do PCI DSS requirements still apply?

Answer: Often, yes. Outsourcing can reduce scope dramatically, but it rarely eliminates PCI DSS requirements entirely. Your environment may still include payment pages, redirects, embedded fields, customer support workflows, administrative access paths, and third-party scripts that can impact the security of payment data entry. 

Vendor relationships themselves create PCI DSS requirements: you must manage responsibilities, ensure vendors maintain appropriate security, and retain evidence that supports your compliance posture. v4.0.1 includes clarifications around customer/TPSP relationships.

To stay safe, map every payment flow end-to-end: customer device → browser → page scripts → payment provider → confirmations → support processes. Then identify which systems can impact the security of those steps. 

Even if you never see PAN, you may still be accountable for controlling what runs on the payment page or who can change the checkout experience.

Q.3: What’s the difference between compensating controls and a customized approach?

Answer: Compensating controls are typically used when a specific PCI DSS requirement cannot be met as stated, but you can implement alternative controls that provide equivalent security. 

The customized approach, emphasized more in v4.x, is a structured way to meet the intent of PCI DSS requirements using tailored controls, with defined objectives, rigorous testing procedures, and strong evidence.

The practical difference is discipline. Both approaches demand strong documentation and defensible outcomes, but the customized approach is designed to provide flexibility in how you achieve security objectives—especially in modern architectures—without treating every deviation as an exception. 

PCI SSC provides resources and templates to support the customized approach and targeted risk analysis concepts.

Q.4: What is the biggest “quick win” for PCI DSS requirements compliance?

Answer: The biggest quick win is usually scope reduction combined with identity and access control cleanup. Reducing storage of PAN, removing systems from the data path through hosted payment solutions, and tightening administrative access can shrink the number of PCI DSS requirements you must implement across the environment.

On the access side, enforce centralized identity, MFA, least privilege roles, and a clean joiner/mover/leaver process. These changes improve both security and audit outcomes quickly because they reduce the likelihood of unauthorized changes and provide cleaner evidence trails (logs, approvals, access reviews).

On the technical side, standardize secure configurations and patch workflows. Even a modest move toward automated baselines and vulnerability remediation SLAs can eliminate recurring assessment findings.

Conclusion

PCI DSS requirements are not just compliance hurdles—they are a practical blueprint for reducing payment risk in real environments. In v4.0.1, the controls remain stable, but clarifications improve how teams interpret applicability, patching expectations, payment page script management, and authentication nuances. 

With future-dated requirements now in effect, organizations should treat PCI DSS requirements as an always-on operating model, not a periodic scramble.

The path to success is consistent across organizations: scope correctly, reduce data exposure where possible, implement strong access control and monitoring, operationalize vulnerability management, and build vendor governance that matches shared responsibility. Then, back it all up with evidence that proves your controls work continuously—not just at audit time.

If you want your PCI DSS requirements program to be both rank-worthy (for customers evaluating trust) and resilient (for security teams), focus on outcomes: fewer places where PAN can exist, fewer people who can change payment systems, faster patching, better visibility, and tighter third-party control. 

Compliance becomes much easier when the environment is genuinely secure—and security becomes much stronger when PCI DSS requirements are treated as a living system rather than a checklist.