1. Decoding PCI DSS: 12 Months of Practical Security & Common Sense.

January. Domain 1: Building Fences

Based on my almost 15 years with PCI, I’ve always wanted to write a quick summary of the PCI DSS assessment process to help people prepare – both customers and less experienced assessors. I know this topic isn’t new, but I am constantly watching people struggling with old problems, and I felt like I could help a bit. This series reflects my personal view; there is always room for improvement, and your feedback is very welcome.

The Summary: What are we actually doing?

Centuries ago, securing a medieval castle was never just about building the thickest stone walls. A lord could have the deepest moat and the heaviest portcullis, yet the castle would fall because a weary cook left a small postern gate unbolted to let in a local merchant, or a spy crawled through a narrow drainage tunnel designed for rainwater.

In the world of PCI DSS, we often focus on the “Frontal Assault”—the massive firewall at the edge. But my years of auditing have taught me that the “Spy” is already inside. They don’t need to break down the front gate; they find the “temporary” tunnel a developer dug for a quick fix, or the “ladder” left leaning against the wall in the form of an open S3 bucket. Securing the CDE isn’t just about the perimeter; it’s about managing every single entry point that people created to make their “daily life easier,” only to realize they’ve made the enemy’s life easier, too.

The fundamental goal of Domain 1 is to create a controlled environment that protects the Cardholder Data Environment (CDE) by managing all traffic entering, leaving, and moving within your network.

It used to be simpler back in the day. Typical network designs have moved from relatively simple, transparent structures with clear CDE boundaries to complex hybrid environments with legacy systems, cloud migration artifacts, and multi-cloud interconnections. In a large network with many segments and inter-application communications, controlling traffic between CDE and non-CDE is hard – and in a cloud/hybrid environment, it is even harder.

Three Common Pitfalls (Which We Often Encounter)

1. Network Security Controls are not just ACLs/NSPs

• In addition to Access Control Lists and Network Security Policies, make sure you control shared services and resources that may allow access from non-CDE to CDE.
• These may include shared file systems, databases, S3 buckets, backup pools, IAM, SNS, SQS, or Lambda functions. The list is long.
• Ask yourself: if a non-CDE component is compromised, will the CDE be affected via a shared resource?
• Your segmentation testing must consider these shared resources and not just rely on a simple nmapscan from one segment to another. Please read my another article on deep dive into segmentation testing.

2. Proper Change Management is a Must

• You must control changes to your network configurations, maintain related records, and always document who, when, why, and by who network security controls are changed.
• If changes are temporary, ensure access is removed when no longer needed. Semi-annual rules review is only one of possible tools, but should be considered as last resort not as main control.
• Restrict allowed access to only necessary ports, protocols, and cipher suites.
• It must become an automatic part of your network management process – no change without documenting it and having it approved.

3. The Shared Responsibility Trap

• If you outsource controls to a Cloud Service Provider (CSP), ensure information security responsibilities are formally and clearly defined.
• You must fully understand what is covered by the CSP and what is assigned to you. We recommend to document responsibility matrix, to clearly document which responsibilities are covered internally, as matrixes provided by CSP are very generalised.
• No single PCI DSS requirement must be left unattended.

Assessment Tips & Tricks

• Self-Assess First: Assess your own environment before the QSA’s visit to identify and fix obvious gaps.
• Don’t Panic: Identified gaps are indicators of weak high-level security controls rather than personal faults. Improve these together with your assessor; the QSA is here to help.
• Daily Ops Over Compliance: Moving from “How do I pass this time?” to “I made this part of my daily operations” is a huge step toward cyber resilience.

Typical Evidence Required

PCI DSS Requirement	Evidence Required	Tryggr’s Comment
1.1.1	Network diagrams, policies, and hardening standards	We don’t appreciate “policy just to have a policy.” Make sure it reflects reality and having a current diagram is your practice.
1.1.2	Role and responsibility definitions	These can be part of job descriptions, your scope definition, or high-level policies.
1.2.3/1.2.4	Detailed Network and Data Flow diagrams	These should be up-to-date, detailed enough, and READABLE to whoever wants to read the report.
1.2.5	Documented business need for ports/protocols	Auditors love to spot 0.0.0.0/0 rules, ‘test’ or ‘temporary’ rules that live forever.
1.2.7	Evidence of semi-annual NSC review	Who is doing that? How do you do it for perhaps thousands of entries? What do you do if you discover a problem?
1.3.1 – 1.4.5	Extracts from ACLs or Cloud NSPs	We love to use ScoutSuite to automate this part of the cloud audit.
1.4.1/1.4.4	Extracts from ACLs or Cloud NSPs	Include objects like S3 buckets and Lambda functions that may break segmentation.
1.5.1	Laptop host-based firewall/antimalware settings	Tricky if you are a local admin; make sure you document and authorize the usage of that role.

Need assistance?

If you need any help while preparing for your assessment or would like to have quick call about PCI DSS, 3DS, PIN Security, P2PE or DORA compliance, please feel free to reach out to us at Trausta. We’re 
always here to ensure a smooth and secure compliance process.

Next Month: Domain 2 – Changing the Keys to the Kingdom (Vendor Defaults).