PCI DSS
PCI DSS Readiness Support in Oakville
The cheapest PCI programme is the smallest one. Before implementing a single control, the question worth answering is how much of your environment genuinely needs to be in scope.
At a glance
- Scope definition and cardholder data discovery
- Segmentation to reduce what is in scope
- Technical control implementation and evidence
- Readiness support — we are not a QSA
Scope first, controls second
PCI DSS applies to the cardholder data environment: the systems that store, process or transmit cardholder data, plus anything connected to them or able to affect their security. That last clause is what catches organisations out — a flat network makes almost everything in-scope, including the workstation in reception.
We start by finding where card data actually flows. Payment terminals and how they connect. E-commerce checkout arrangements and whether the page is redirected or hosted. Phone payments and whether anyone writes a number down. Email — cardholder data arriving in a mailbox creates scope nobody planned for. Historic data sitting in old files or backups counts too.
- Cardholder data discovery across systems and processes
- Payment flow mapping, including phone and email paths
- Terminal and gateway integration review
- Identification of unnecessary storage to eliminate
- Scope determination and validation
Reducing scope through segmentation
Segmentation is the highest-value technical work in most PCI programmes. Isolating payment systems onto their own network segment, with controlled and documented access, can move the majority of an environment out of scope — which reduces both the control burden and the ongoing evidence effort permanently.
Where feasible, we also look at removing card data from the environment altogether: point-to-point encrypted terminals, hosted payment pages, and tokenisation through the payment provider. Not storing data is always cheaper than protecting it.
- Network segmentation design and implementation
- Documented and controlled access into the segment
- P2PE terminal and hosted-page options reviewed
- Tokenisation to eliminate stored card data
- Segmentation validation testing
Technical controls within scope
Inside the cardholder data environment the requirements are specific and mostly familiar: secure configuration standards with defaults changed, firewall and access control rules that are documented and reviewed, multi-factor authentication for administrative and remote access, unique user IDs with least privilege, and prompt patching against a defined vulnerability management process.
Alongside those sit endpoint protection, logging with sufficient retention and periodic review, file integrity monitoring where required, vulnerability scanning at the mandated cadence, and penetration testing including segmentation validation. Vendor exposure matters as well — any third party touching the payment path forms part of your risk picture and needs documented assessment.
- Secure configuration baselines and default credential removal
- Documented firewall and access control rule sets
- MFA for administrative and remote access
- Vulnerability management, scanning and patching cadence
- Logging, retention, monitoring and review records
- Penetration testing and segmentation validation
- Vendor and service provider assessment records
What we do not claim
Griffin IT Group is not a Qualified Security Assessor and does not perform formal PCI DSS assessments or issue attestations of compliance. We provide technical readiness support: scope work, control implementation, evidence preparation, remediation and coordination with your acquirer, payment provider or QSA where one is engaged.
We also do not guarantee a compliance outcome. Validation requirements differ by merchant level and acquirer, and the determination rests with those parties.
Keep exploring
Related Oakville services
Most engagements combine several of these. Follow the thread that matches the problem you are trying to solve.
Questions
Frequently asked questions
- We only take a few card payments. Does PCI still apply?
- Yes — PCI DSS applies to any organisation that stores, processes or transmits cardholder data, though validation requirements scale with volume and channel. Low-volume merchants often complete a self-assessment questionnaire, and choosing the correct SAQ type depends on your payment method. Getting that classification right early avoids substantial unnecessary work.
- Can you complete our self-assessment questionnaire for us?
- The SAQ is your attestation and must be completed by you. We help you understand each requirement, establish the truthful answer, implement what is missing and assemble supporting evidence so the answers you give are defensible.
- Does using a hosted payment page remove our obligations?
- It can reduce them significantly, but not to zero. The systems that deliver and secure your checkout, your redirect configuration and your service provider due diligence remain relevant. The specific SAQ type depends on the integration method, which is worth confirming rather than assuming.
- How does penetration testing fit into PCI?
- PCI DSS requires periodic penetration testing and, where segmentation is used to reduce scope, testing to validate that the segmentation holds. We scope that testing under written authorisation with defined rules of engagement, the same as any other engagement.
Start by shrinking the problem
A scope review often removes more cost from a PCI programme than any control you could implement. Let us map where card data actually flows.