ChatGPT














I’ll frame this at the useful business/operator level: what PCI compliance is, what it is not, and why it matters operationally rather than as paperwork.

Thought for 6s
PCI compliance means a business is following the Payment Card Industry Data Security Standard, usually called PCI DSS. It applies to organizations that store, process, or transmit cardholder data. The PCI Security Standards Council describes PCI DSS as a baseline of technical and operational requirements for protecting payment account data. 

Plain English: if your business accepts card payments, PCI is the rulebook for protecting card data and proving you handle payments safely.

PCI compliance is not just “I use Square/Stripe/Clover, so I’m fine.” Those providers reduce your scope, but the business still has responsibilities: how cards are accepted, whether card numbers are written down, whether staff key cards manually, whether devices are secure, whether systems are patched, whether access is controlled, and whether the merchant completes the required validation process.

The current PCI DSS version is v4.0.1, published by the PCI Security Standards Council in June 2024 as a limited revision to v4.0. The Council said it clarified wording and guidance but did not add or remove requirements. 

At a high level, PCI compliance covers things like:

Secure networks and systems
Firewalls, secure configurations, no default passwords, protected payment devices.

Protection of cardholder data
Do not store sensitive card data unless absolutely necessary. Encrypt/transmit data securely.

Vulnerability management
Keep systems patched. Use anti-malware where needed. Fix known weaknesses.

Access control
Only the right people get access. Unique user IDs. Strong authentication. MFA where required.

Monitoring and testing
Logs, scans, system monitoring, vulnerability testing, change awareness.

Security policy and process
Written procedures, staff training, incident response, vendor oversight.

For small businesses, PCI usually shows up as a Self-Assessment Questionnaire, often through the processor. That is the form where the merchant confirms how they accept cards and whether they meet the required controls. Some merchants also need vulnerability scans depending on how their card environment works.

The operational point for CertumCore thinking:

PCI compliance is not just cybersecurity paperwork. It affects payment behavior.

Bad PCI posture can create:

non-validation fees, like monthly PCI penalty charges

higher dispute/fraud exposure

risky manual/keyed payment behavior

unclear responsibility after a payment incident

processor/account review problems

hidden operational drift where “payments are working” but the underlying control state is weak

The cleanest description:

PCI compliance is the payment industry’s control framework for proving that cardholder data is handled securely across people, systems, devices, vendors, and transaction workflows.

For a merchant, the practical question is not only:
“Are we PCI compliant?”

The better question is:

“Can we prove our card-payment process is operating the way we claim it is?”



PCI-DSS-v4_0_1.pdf
PDF
can we simplify this into levels of secuirty separated by edge triggers like must be segmented or somethign like that ?

Thought for 9s
Yes. The clean way to simplify PCI is to stop thinking of it as “12 requirements” first and think of it as security levels triggered by payment exposure.

PCI gets heavier when the business crosses certain edge triggers: storing card data, using Wi-Fi near payments, connecting POS to normal office networks, using remote access, building payment pages, using third parties, or failing to segment the cardholder data environment.

PCI DSS itself says scope includes systems, people, and processes that store/process/transmit cardholder data, plus systems that can impact that environment. It also says segmentation is not technically mandatory, but without adequate segmentation, a flat network can bring the entire network into PCI scope. 


Simple PCI Security Levels
Level 0 — Outsourced / Minimal Touch
Business uses Stripe, Square, Clover, hosted checkout, or payment links. No card numbers are handled directly.

Typical state:

“We accept payments, but we do not touch raw card data.”

Controls needed:

Use trusted processor/payment platform.

Complete the correct SAQ.

Keep login access secure.

Use MFA.

Do not write down, email, text, or store card numbers.

Know who your payment vendors are.

Edge trigger to next level:
Someone manually keys cards, receives card numbers by phone/email/text, stores card info, or uses terminals connected to the business network.

Level 1 — Payment Device / Terminal Exposure
Business uses physical terminals, card readers, POS systems, or keyed payments.

Typical state:

“We don’t store card data, but payment devices are in our environment.”

Controls needed:

Secure payment devices.

Change default passwords.

Restrict who can use admin functions.

Inspect devices for tampering.

Keep POS/payment software updated.

Limit manual/keyed entry.

Document payment flow.

Edge trigger to next level:
The POS or terminal shares network space with office computers, Wi-Fi, cameras, phones, printers, or general business systems.

Level 2 — Network Scope / Segmentation Required in Practice
Payment devices or payment systems touch the same network as other business systems.

This is where your instinct is right: segmentation becomes the practical dividing line.

PCI says segmentation is not a formal requirement, but it is strongly recommended because it can reduce assessment scope, cost, implementation difficulty, and payment-data risk. Without adequate segmentation, the whole network may be in scope. 


Typical state:

“Payments work, but we need to prove the payment environment is isolated from the rest of the business.”

Controls needed:

Separate POS/payment network from office network.

Firewall or ACL between payment and non-payment systems.

Deny unnecessary inbound/outbound traffic.

Document network diagram.

Document payment data-flow diagram.

Review firewall/security rules at least every six months.

Block unauthorized wireless paths into the CDE.

Edge trigger to next level:
Business stores cardholder data, full PAN, reports with PAN, recordings, spreadsheets, logs, or backups containing card data.

Level 3 — Stored Card Data
Cardholder data exists somewhere inside the business environment.

This is a big jump. PCI gets serious here.

Typical state:

“We have card data at rest somewhere.”

Controls needed:

Keep stored account data to a minimum.

Define retention period.

Securely delete data when no longer needed.

Render stored PAN unreadable through truncation, tokenization, strong cryptography, or approved hashing.

Restrict who can see full PAN.

Protect cryptographic keys if encryption is used.

PCI specifically says PAN is the defining factor for cardholder data, and if PAN is stored, processed, or transmitted, a CDE exists. It also says sensitive authentication data cannot be stored after authorization, even if encrypted. 


Edge trigger to next level:
The business builds, hosts, redirects, embeds, or controls payment software, payment pages, custom checkout, APIs, or integrations.

Level 4 — Payment Software / E-commerce / Custom Systems
Business systems can affect how card data is collected, redirected, submitted, processed, or secured.

Typical state:

“Even if we don’t store card data, our systems can affect payment security.”

Controls needed:

Secure software development.

Patch management.

Vulnerability management.

Web/app security.

Change control.

Logging and monitoring.

Access control.

Vendor/plugin/script review.

Secure configuration of servers, cloud, DNS, redirects, forms, checkout flows.

PCI says systems that do not directly store/process/transmit PAN can still be in scope if they can impact the security of cardholder data, such as a web server controlling generation of a payment form or page. 


Edge trigger to next level:
Business provides payment services, stores/processes/transmits card data for others, manages customer payment environments, or acts as a service provider.

Level 5 — Service Provider / High Responsibility
The company affects other businesses’ payment environments.

Typical state:

“Our service can impact someone else’s cardholder data environment.”

Controls needed:

Full responsibility matrix.

Customer/vendor responsibility documentation.

Annual compliance evidence.

Strong logging, monitoring, access control, incident response.

Service provider PCI obligations.

Support customer requests for compliance evidence.

Clear definition of which PCI controls are yours, theirs, or shared.

PCI says customers using third-party service providers remain responsible for their own compliance, and third-party responsibilities must be clearly understood and monitored. 


The “Edge Trigger” Model
Here is the clean CertumCore-style version:

Trigger	Security consequence
Accept cards only through hosted checkout/payment links	Minimal PCI scope, mostly vendor + access hygiene
Staff manually keys cards	Higher operational/payment risk
Card data enters email/text/paper/phone notes	That channel may enter PCI scope unless data is deleted and prevented going forward
POS shares network with office devices	Segmentation becomes the practical control line
Wi-Fi connects to or can reach payment systems	Wireless controls and NSCs matter
Business stores PAN/cardholder data	Data retention, encryption/tokenization, masking, deletion, and key management apply
Custom payment page, redirect, API, or checkout	Software/security/change-control scope increases
Third party handles payment functions	Vendor oversight and responsibility mapping required
Business supports other merchants’ payment systems	Service-provider-level obligations begin
The simplest working phrase
PCI compliance increases by exposure. The more directly a business touches card data, payment systems, payment networks, or systems that can influence payment security, the stronger the control layer must become.

And the killer practical line:

Segmentation is not always mandatory on paper, but once payment systems share space with normal business systems, segmentation becomes the difference between a contained payment environment and dragging the whole business network into scope.


ok each elvel here go ahead and put it in one big copy paste grey box and ill copy that over...this is truly helpful bc this is how i think when ilook at this type of thing 

Thought for a couple of seconds
Absolutely. This is the right mental model: PCI as exposure-triggered security levels.

PCI COMPLIANCE — SIMPLIFIED SECURITY LEVEL MODEL

Core idea:
PCI compliance increases by exposure.

The more directly a business touches card data, payment systems, payment networks, or systems that can influence payment security, the stronger the control layer must become.

PCI is not just “do we accept cards?”
The better question is:

“What payment exposure exists, and what security level does that exposure trigger?”


============================================================
LEVEL 0 — OUTSOURCED / MINIMAL TOUCH
============================================================

Plain-English state:
The business accepts card payments, but does not directly handle raw card data.

Examples:
- Stripe Payment Links
- Square checkout links
- Clover hosted checkout
- Hosted invoice payment pages
- Third-party checkout where the customer enters card data directly into the provider’s environment

Typical statement:
“We accept payments, but we do not touch raw card data.”

Primary risk:
The business may assume the processor handles everything and ignore its own remaining responsibilities.

Controls needed:
- Use a reputable payment processor or hosted checkout provider.
- Complete the correct SAQ / processor compliance questionnaire.
- Secure payment platform logins.
- Use MFA on payment accounts.
- Limit admin access.
- Do not collect card numbers by email, text, paper, chat, or voicemail.
- Do not store card numbers in spreadsheets, notes, CRMs, ticket systems, or inboxes.
- Know which vendors are involved in payment acceptance.
- Keep basic payment process documentation.

Edge trigger to Level 1:
Staff manually keys cards, receives card numbers, uses physical terminals, or handles payment devices.


============================================================
LEVEL 1 — PAYMENT DEVICE / TERMINAL EXPOSURE
============================================================

Plain-English state:
The business uses payment devices or staff-assisted payment entry, but does not intentionally store card data.

Examples:
- Countertop terminals
- Mobile card readers
- POS devices
- Tap/chip/swipe terminals
- Merchant-keyed transactions
- Phone payments entered by staff
- Card-present retail or service business

Typical statement:
“We do not store card data, but payment devices operate inside our business.”

Primary risk:
The payment device becomes a control point. Staff behavior, device handling, keyed entry, and physical tampering matter.

Controls needed:
- Secure payment devices physically.
- Inspect devices for tampering or substitution.
- Restrict who can use payment admin functions.
- Change vendor defaults where applicable.
- Keep payment devices and POS software updated.
- Train staff not to write down or casually handle card data.
- Limit keyed/manual entry where possible.
- Track who has access to payment systems.
- Document the payment flow from customer payment to processor submission.
- Understand whether receipts, reports, or screenshots expose cardholder data.

Edge trigger to Level 2:
Payment devices, POS systems, or payment terminals share network space with office computers, Wi-Fi, cameras, phones, printers, or general business systems.


============================================================
LEVEL 2 — NETWORK SCOPE / SEGMENTATION REQUIRED IN PRACTICE
============================================================

Plain-English state:
Payment systems touch the business network, or other business systems can reach the payment environment.

Examples:
- POS on same network as office PCs
- Payment terminal on normal business Wi-Fi
- Back-office computer connects to POS system
- Shared router/firewall with no clear payment separation
- Cameras, printers, phones, guest Wi-Fi, or admin laptops near payment systems
- Flat network where everything can talk to everything

Typical statement:
“Payments work, but we need to prove the payment environment is isolated from the rest of the business.”

Primary risk:
Without segmentation, the payment environment is not contained. A normal office system can become a path into payment scope.

Controls needed:
- Separate POS/payment network from office/general network.
- Use firewall rules, VLANs, ACLs, or other network security controls.
- Deny unnecessary inbound traffic to the payment environment.
- Deny unnecessary outbound traffic from the payment environment.
- Document allowed ports, protocols, and business justification.
- Maintain a network diagram.
- Maintain a payment data-flow diagram.
- Review network/security rules at least every six months.
- Control wireless access into the cardholder data environment.
- Treat out-of-scope networks as untrusted unless their controls are verified.
- Prevent payment systems from being reachable by unnecessary systems.

Key principle:
Segmentation may not always be mandatory on paper, but once payment systems share space with normal business systems, segmentation becomes the practical dividing line.

Clean phrase:
“Segmentation is the difference between a contained payment environment and dragging the whole business network into scope.”

Edge trigger to Level 3:
The business stores cardholder data, full PAN, card reports, call recordings, spreadsheets, logs, screenshots, paper forms, or backups containing card data.


============================================================
LEVEL 3 — STORED CARD DATA
============================================================

Plain-English state:
Cardholder data exists somewhere inside the business environment.

Examples:
- Full card numbers stored in files
- PAN in spreadsheets
- Card numbers in email
- Card data in CRM notes
- Payment forms kept on paper
- Voicemail/call recordings with card numbers
- Screenshots showing card data
- Logs containing PAN
- Backups containing card data
- Reports with more than masked card details

Typical statement:
“We have card data at rest somewhere.”

Primary risk:
Stored card data creates a major scope increase. If data exists, it must be located, protected, minimized, and eventually destroyed.

Controls needed:
- Identify all locations where account data exists.
- Keep stored account data to the minimum necessary.
- Define retention periods.
- Securely delete data when no longer needed.
- Do not store sensitive authentication data after authorization.
- Render stored PAN unreadable through approved methods such as truncation, tokenization, strong cryptography, or approved hashing.
- Mask PAN when displayed unless there is a legitimate business need.
- Restrict who can view full PAN.
- Restrict copying or relocating PAN.
- Protect encryption keys if encryption is used.
- Document data retention and disposal processes.
- Verify at least every three months that expired stored data has been deleted or rendered unrecoverable.

Important distinction:
Masking is for display.
Encryption/tokenization/truncation protects stored data.
They are not the same thing.

Edge trigger to Level 4:
The business builds, hosts, redirects, embeds, or controls payment software, payment pages, payment forms, APIs, checkout flows, scripts, or integrations.


============================================================
LEVEL 4 — PAYMENT SOFTWARE / E-COMMERCE / CUSTOM SYSTEMS
============================================================

Plain-English state:
Business systems can affect how card data is collected, redirected, submitted, processed, or secured.

Examples:
- E-commerce website
- Custom checkout page
- Embedded payment form
- Redirect to payment processor
- Payment API integration
- Website script that controls checkout behavior
- Plugin/module that affects payment collection
- Custom software touching transaction flow
- Cloud systems involved in payment processing
- Web server generating or controlling payment pages

Typical statement:
“Even if we do not store card data, our systems can affect payment security.”

Primary risk:
A system does not need to store card data to be in scope. If it can influence the payment page, payment redirect, transaction submission, or security of the payment path, it may affect PCI scope.

Controls needed:
- Secure software development practices.
- Patch management.
- Vulnerability management.
- Change control.
- Logging and monitoring.
- Secure authentication.
- Access control by business need.
- MFA for administrative access.
- Secure configuration of servers, cloud services, DNS, redirects, forms, and checkout paths.
- Review third-party scripts/plugins.
- Protect administrative interfaces.
- Test systems and networks regularly.
- Maintain documentation of payment data flows.
- Confirm that payment software is properly configured and securely implemented.

Key principle:
A hosted processor reduces scope only if the business systems cannot compromise, alter, intercept, or misdirect the payment flow.

Edge trigger to Level 5:
The business provides payment services, manages payment environments for others, stores/processes/transmits card data for customers, or provides systems that can affect another merchant’s cardholder data environment.


============================================================
LEVEL 5 — SERVICE PROVIDER / HIGH RESPONSIBILITY
============================================================

Plain-English state:
The company affects other businesses’ payment environments or cardholder data security.

Examples:
- Payment service provider
- Managed payment infrastructure
- SaaS connected to customer payment flows
- Vendor storing payment data for customers
- Vendor managing customer firewalls, POS systems, payment networks, or security controls
- Cloud/payment platform used by merchants
- Company that supports payment processing, settlement, routing, storage, or security functions for others

Typical statement:
“Our service can impact someone else’s cardholder data environment.”

Primary risk:
The company is no longer only protecting itself. Its controls may become part of another entity’s PCI compliance.

Controls needed:
- Define service provider responsibilities.
- Maintain customer/vendor responsibility matrix.
- Document which PCI controls are the provider’s responsibility, the customer’s responsibility, or shared.
- Provide compliance evidence when required.
- Maintain strong access control.
- Maintain logging and monitoring.
- Maintain vulnerability management.
- Maintain incident response procedures.
- Secure customer data and environments.
- Support customer requests for PCI compliance information.
- Monitor third-party dependencies.
- Validate service provider compliance as required by payment brands, acquirers, or customers.

Key principle:
Using a compliant third party does not automatically make the customer compliant. Responsibility must be mapped, documented, and monitored.


============================================================
EDGE TRIGGER SUMMARY
============================================================

Trigger:
Business accepts cards only through hosted checkout or payment links.

Security consequence:
Minimal PCI scope, mostly vendor management, access hygiene, MFA, and correct SAQ.


Trigger:
Staff manually keys cards.

Security consequence:
Higher operational risk, higher card-handling exposure, stronger staff/process controls needed.


Trigger:
Card data enters email, text, paper, voicemail, chat, or tickets.

Security consequence:
That channel may enter PCI scope unless the data is securely deleted and controls are added to prevent recurrence.


Trigger:
Payment devices are used in the business.

Security consequence:
Device security, tamper inspection, access control, default-password control, and staff handling procedures matter.


Trigger:
POS/payment systems share network space with normal business devices.

Security consequence:
Segmentation becomes the practical control line. Without it, the broader network may be pulled into scope.


Trigger:
Wireless can reach payment systems.

Security consequence:
Wireless controls, network security controls, and default-deny boundaries matter.


Trigger:
PAN/cardholder data is stored.

Security consequence:
Retention, deletion, masking, encryption/tokenization/truncation, key management, and access restriction apply.


Trigger:
Sensitive authentication data is stored after authorization.

Security consequence:
Major violation risk. SAD should not be stored after authorization, even if encrypted.


Trigger:
Business controls payment page, redirect, API, script, plugin, or checkout flow.

Security consequence:
Software security, change control, vulnerability management, and web/payment-flow verification apply.


Trigger:
Third party handles payment functions.

Security consequence:
Vendor oversight, compliance status monitoring, and responsibility mapping are required.


Trigger:
Business supports other merchants’ payment systems.

Security consequence:
Service-provider responsibility begins. Documentation, evidence, monitoring, and customer-facing compliance obligations increase.


============================================================
ONE-LINE MODEL
============================================================

PCI compliance is exposure-based security.

The more a business touches card data, payment devices, payment networks, payment software, or systems that can influence payment security, the more control, segmentation, documentation, monitoring, and proof are required.


============================================================
CERTUMCORE-STYLE PRACTICAL PHRASE
============================================================

“PCI is not just a compliance checkbox. It is a control map showing where payment data can appear, what systems can affect it, and what proof exists that the payment environment is actually contained.”
Grounded in the uploaded PCI DSS v4.0.1 language on scope, segmentation, storage, third-party responsibility, and system components that can impact cardholder data security. 



does the booklet say anything about what someone like me can actually do for a business setting this up?  for example, I can't make you cmpliant since that is a governing body that does that but I can certainly read this book and do for a company what the specs say....and of course then the owner can complete the QAC...

Thought for 17s
Yes — that is exactly the lane.

But tighten the language:

You should not say:

“I can make you PCI compliant.”

Better:

“I help businesses interpret PCI DSS requirements, map their payment environment, identify gaps, implement practical controls, organize evidence, and prepare the owner to complete the appropriate SAQ/AOC process with their processor or assessor.”

That is a very real business service.

PCI DSS itself separates the requirements/testing procedures from the actual validation/reporting process. The document says PCI DSS provides baseline technical and operational requirements, includes testing procedures, and gives guidance to help entities prepare for, conduct, and report an assessment. 


Your lane is basically:

PCI READINESS / PAYMENT SECURITY IMPLEMENTATION SUPPORT

I do not certify PCI compliance.
I do not act as the payment brand, acquirer, QSA, or governing authority.
I do not guarantee that a merchant will pass validation.

What I can do:
- Identify how the business accepts card payments.
- Map where card data enters, moves, appears, or could appear.
- Determine what systems, people, processes, and vendors may be in PCI scope.
- Identify whether the business has a flat network or segmented payment environment.
- Review payment devices, POS setup, Wi-Fi exposure, admin access, and vendor access.
- Help document network diagrams and payment data-flow diagrams.
- Compare the business environment against PCI DSS requirements.
- Identify gaps between current practice and required/expected controls.
- Recommend practical remediation steps.
- Help implement security controls where technically appropriate.
- Help organize evidence the owner may need for SAQ, AOC, processor review, or assessor review.
- Help the business understand which responsibilities belong to the merchant, processor, payment platform, IT provider, or other third party.
- Help prepare the owner/operator to answer the processor’s compliance questionnaire more accurately.

Important boundary:
The merchant/business owner remains responsible for its own PCI compliance and validation.
The processor, acquirer, payment brand, or qualified assessor determines what validation is required.
And yes, your instinct on the SAQ is right. The business owner/merchant is the one making the compliance attestation. You can support the work, organize the environment, explain the requirements, document the evidence, and help close gaps — but the owner should not blindly sign a questionnaire just because “IT said it was fine.”

This is where CertumCore can be sharp:

“We do not sell certification. We prepare the operating reality behind the certification.”

The uploaded PCI document also makes your lane stronger because it says the first step in preparing for PCI assessment is for the entity to accurately determine scope, including locations and flows of account data and systems connected to or capable of impacting the CDE. That is absolutely something you can help a business do. 


The clean offer is not “PCI compliance.”

The clean offer is:

PCI Readiness & Payment Environment Verification

Or even stronger:

Payment Security Scope Review

Deliverable:

CertumCore PCI Readiness / Payment Scope Review

Purpose:
To help the business understand its payment-security exposure before completing processor compliance forms or engaging formal PCI validation.

Review Areas:
1. Payment acceptance methods
2. Card-data entry points
3. Cardholder-data storage risk
4. POS/payment device setup
5. Network segmentation
6. Wireless exposure
7. Admin and vendor access
8. Payment software / hosted checkout / redirect behavior
9. Third-party responsibility mapping
10. Documentation and evidence readiness

Output:
- Plain-language scope summary
- Payment data-flow observations
- Systems likely in or near PCI scope
- Gaps requiring owner attention
- Practical remediation recommendations
- Evidence checklist for SAQ / processor review
- Boundary statement: not a certification or legal attestation
This is a legit lane because PCI is full of “determine, document, verify, maintain, review, restrict, monitor.” That is operational verification work. You are not impersonating a governing body. You are helping the merchant stop guessing before they sign paperwork.


ok what page could this go on as a deliverable

Thought for a second
Yes. Put this as a service deliverable page, not buried inside general PCI education.

Best placement:

CertumCore Website Placement

Primary page:
Services / Payment Security Scope Review

Alternate page names:
- PCI Readiness Review
- Payment Environment Verification
- Payment Security Scope Review
- PCI Scope & Readiness Review
- Payment Control Readiness Review

Best fit:
A dedicated service page under CertumCore’s payment operations / verification services.

Suggested page structure:

1. Hero Section

Payment Security Scope Review

Before completing PCI questionnaires or assuming your processor has everything covered, CertumCore helps identify how card data, payment devices, networks, vendors, and business processes actually interact.

We do not certify PCI compliance.
We help verify the operating environment behind the compliance claim.


2. Who This Is For

This review is for businesses that:

- Accept card payments through POS, terminal, invoice, payment link, website, or phone.
- Are unsure what systems are in payment scope.
- Need help before completing a processor PCI questionnaire.
- Use Square, Stripe, Clover, PayPal, or another processor but do not fully understand remaining merchant responsibilities.
- Have payment devices sharing space with Wi-Fi, office computers, printers, cameras, or general business systems.
- Want a plain-language review before signing an SAQ or compliance attestation.


3. What We Review

Review areas include:

- Payment acceptance methods
- Card-data entry points
- POS and payment-device setup
- Network segmentation
- Wi-Fi/payment exposure
- Admin and vendor access
- Stored card-data risk
- Payment software, checkout, redirect, or hosted payment behavior
- Third-party responsibility mapping
- Evidence readiness for SAQ, AOC, processor review, or assessor review


4. Deliverable

You receive a plain-language Payment Security Scope Summary that identifies:

- How payments are accepted
- Where card data may enter or appear
- Which systems may be in or near PCI scope
- Whether segmentation appears necessary
- Where business practices create exposure
- What documentation is missing
- Which gaps deserve owner attention
- What evidence should be gathered before completing processor compliance forms


5. Boundary Statement

CertumCore does not certify PCI compliance, act as a QSA, payment brand, acquirer, or governing authority, or guarantee validation results.

The business owner remains responsible for its own PCI compliance and any formal attestation.

CertumCore helps the business understand, document, and improve the operating reality before compliance forms are completed.


6. Call to Action

Request Payment Security Scope Review

Send a basic description of how your business accepts card payments, including processor, POS, payment devices, online checkout, and whether payments occur by phone, invoice, website, or in person.
The page should probably sit here:

certumcore.com/services/payment-security-scope-review
Or if you want it cleaner:

certumcore.com/pci-readiness
My strongest recommendation:

/payment-security-scope-review
That sounds less like you are selling “PCI certification” and more like you are selling the actual thing you can do: scope, verify, map, and prepare.


ok make this my pci-readiness html page CertumCore Website Placement

Primary page:
Services / Payment Security Scope Review

Alternate page names:
- PCI Readiness Review
- Payment Environment Verification
- Payment Security Scope Review
- PCI Scope & Readiness Review
- Payment Control Readiness Review

Best fit:
A dedicated service page under CertumCore’s payment operations / verification services.

Suggested page structure:

1. Hero Section

Payment Security Scope Review

Before completing PCI questionnaires or assuming your processor has everything covered, CertumCore helps identify how card data, payment devices, networks, vendors, and business processes actually interact.

We do not certify PCI compliance.
We help verify the operating environment behind the compliance claim.


2. Who This Is For

This review is for businesses that:

- Accept card payments through POS, terminal, invoice, payment link, website, or phone.
- Are unsure what systems are in payment scope.
- Need help before completing a processor PCI questionnaire.
- Use Square, Stripe, Clover, PayPal, or another processor but do not fully understand remaining merchant responsibilities.
- Have payment devices sharing space with Wi-Fi, office computers, printers, cameras, or general business systems.
- Want a plain-language review before signing an SAQ or compliance attestation.


3. What We Review

Review areas include:

- Payment acceptance methods
- Card-data entry points
- POS and payment-device setup
- Network segmentation
- Wi-Fi/payment exposure
- Admin and vendor access
- Stored card-data risk
- Payment software, checkout, redirect, or hosted payment behavior
- Third-party responsibility mapping
- Evidence readiness for SAQ, AOC, processor review, or assessor review


4. Deliverable

You receive a plain-language Payment Security Scope Summary that identifies:

- How payments are accepted
- Where card data may enter or appear
- Which systems may be in or near PCI scope
- Whether segmentation appears necessary
- Where business practices create exposure
- What documentation is missing
- Which gaps deserve owner attention
- What evidence should be gathered before completing processor compliance forms


5. Boundary Statement

CertumCore does not certify PCI compliance, act as a QSA, payment brand, acquirer, or governing authority, or guarantee validation results.

The business owner remains responsible for its own PCI compliance and any formal attestation.

CertumCore helps the business understand, document, and improve the operating reality before compliance forms are completed.


6. Call to Action

Request Payment Security Scope Review

Send a basic description of how your business accepts card payments, including processor, POS, payment devices, online checkout, and whether payments occur by phone, invoice, website, or in person.

Thought for 49s
Done — I made the HTML page here:

Download pci-readiness.html

I set it up as a standalone CertumCore service page with the safer framing: PCI Readiness / Payment Security Scope Review, not “PCI certification.”

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
  <title>PCI Readiness Review | CertumCore</title>
  <meta name="description" content="CertumCore helps businesses understand payment-security exposure, PCI scope, payment-device risk, network segmentation, vendor responsibilities, and evidence readiness before completing PCI questionnaires or attestations." />
  <meta name="robots" content="index, follow" />
  <style>
    :root {
      --bg: #f4f1ec;
      --paper: #fffaf2;
      --ink: #1e1e1e;
      --muted: #5e5a53;
      --line: #2a2a2a;
      --accent: #3b475c;
      --accent-soft: #e8e3d8;
      --box: #ebe6dc;
    }

    * {
      box-sizing: border-box;
    }

    body {
      margin: 0;
      font-family: Georgia, "Times New Roman", serif;
      background: var(--bg);
      color: var(--ink);
      line-height: 1.55;
    }

    a {
      color: inherit;
    }

    .page {
      width: min(1120px, calc(100% - 32px));
      margin: 0 auto;
    }

    header {
      border-bottom: 2px solid var(--line);
      background: var(--paper);
    }

    .nav {
      display: flex;
      align-items: center;
      justify-content: space-between;
      gap: 24px;
      padding: 22px 0;
    }

    .brand {
      display: flex;
      flex-direction: column;
      letter-spacing: 0.02em;
    }

    .brand strong {
      font-size: 1.25rem;
      text-transform: uppercase;
      letter-spacing: 0.08em;
    }

    .brand span {
      color: var(--muted);
      font-size: 0.92rem;
    }

    .nav-links {
      display: flex;
      flex-wrap: wrap;
      gap: 16px;
      font-size: 0.95rem;
    }

    .nav-links a {
      text-decoration: none;
      border-bottom: 1px solid transparent;
    }

    .nav-links a:hover,
    .nav-links a:focus {
      border-bottom-color: var(--ink);
    }

    .hero {
      padding: 76px 0 54px;
      border-bottom: 1px solid var(--line);
    }

    .eyebrow {
      font-family: "Courier New", monospace;
      text-transform: uppercase;
      letter-spacing: 0.12em;
      font-size: 0.82rem;
      color: var(--accent);
      margin-bottom: 18px;
    }

    h1 {
      font-size: clamp(2.45rem, 6vw, 5.2rem);
      line-height: 0.98;
      margin: 0 0 24px;
      letter-spacing: -0.045em;
      max-width: 930px;
    }

    .hero p {
      max-width: 790px;
      font-size: clamp(1.12rem, 2vw, 1.38rem);
      color: var(--muted);
      margin: 0 0 18px;
    }

    .claim-box {
      margin-top: 34px;
      max-width: 820px;
      border: 2px solid var(--line);
      background: var(--box);
      padding: 24px;
      font-size: 1.12rem;
    }

    .claim-box strong {
      display: block;
      margin-bottom: 6px;
      font-size: 1.18rem;
    }

    main {
      padding: 46px 0 70px;
    }

    section {
      padding: 36px 0;
      border-bottom: 1px solid rgba(42, 42, 42, 0.35);
    }

    .section-grid {
      display: grid;
      grid-template-columns: 280px 1fr;
      gap: 44px;
      align-items: start;
    }

    h2 {
      margin: 0;
      font-size: 1.55rem;
      line-height: 1.15;
      letter-spacing: -0.02em;
    }

    .section-label {
      font-family: "Courier New", monospace;
      font-size: 0.82rem;
      color: var(--accent);
      text-transform: uppercase;
      letter-spacing: 0.1em;
      margin-bottom: 8px;
    }

    .content p {
      margin-top: 0;
      color: var(--muted);
      font-size: 1.05rem;
    }

    ul {
      margin: 0;
      padding-left: 20px;
    }

    li {
      margin: 9px 0;
      padding-left: 4px;
    }

    .cards {
      display: grid;
      grid-template-columns: repeat(2, minmax(0, 1fr));
      gap: 16px;
    }

    .card {
      border: 1px solid var(--line);
      background: var(--paper);
      padding: 20px;
      min-height: 100%;
    }

    .card h3 {
      margin: 0 0 10px;
      font-size: 1.08rem;
    }

    .card p {
      margin: 0;
      font-size: 0.98rem;
    }

    .deliverable {
      border: 2px solid var(--line);
      background: var(--paper);
      padding: 28px;
    }

    .boundary {
      border-left: 6px solid var(--accent);
      background: var(--accent-soft);
      padding: 24px;
    }

    .cta {
      display: grid;
      grid-template-columns: 1fr auto;
      gap: 28px;
      align-items: center;
      padding: 34px;
      border: 2px solid var(--line);
      background: var(--accent);
      color: #fff;
    }

    .cta h2,
    .cta p {
      color: #fff;
      margin: 0;
    }

    .cta p {
      margin-top: 10px;
      opacity: 0.92;
      max-width: 760px;
    }

    .button {
      display: inline-block;
      padding: 14px 20px;
      border: 2px solid #fff;
      text-decoration: none;
      font-weight: bold;
      background: #fff;
      color: var(--accent);
      white-space: nowrap;
    }

    .fine-print {
      font-size: 0.92rem;
      color: var(--muted);
      margin-top: 22px;
      font-family: "Courier New", monospace;
    }

    footer {
      border-top: 2px solid var(--line);
      background: var(--paper);
      padding: 28px 0;
      color: var(--muted);
      font-size: 0.94rem;
    }

    footer .page {
      display: flex;
      justify-content: space-between;
      gap: 24px;
      flex-wrap: wrap;
    }

    @media (max-width: 800px) {
      .nav {
        align-items: flex-start;
        flex-direction: column;
      }

      .section-grid,
      .cta {
        grid-template-columns: 1fr;
      }

      .cards {
        grid-template-columns: 1fr;
      }

      .hero {
        padding-top: 52px;
      }

      .button {
        text-align: center;
      }
    }
  </style>
</head>
<body>
  <header>
    <div class="page nav">
      <a class="brand" href="/" aria-label="CertumCore Home">
        <strong>CertumCore</strong>
        <span>Expected vs Actual — Verified</span>
      </a>
      <nav class="nav-links" aria-label="Primary navigation">
        <a href="/">Home</a>
        <a href="/services">Services</a>
        <a href="/privacy.html">Privacy</a>
        <a href="/security.html">Security</a>
        <a href="mailto:support@certumcore.com?subject=Payment%20Security%20Scope%20Review">Contact</a>
      </nav>
    </div>
  </header>

  <main>
    <div class="page">
      <section class="hero" aria-labelledby="hero-title">
        <div class="eyebrow">PCI Readiness / Payment Security Scope Review</div>
        <h1 id="hero-title">Payment Security Scope Review</h1>
        <p>
          Before completing PCI questionnaires or assuming your processor has everything covered, CertumCore helps identify how card data, payment devices, networks, vendors, and business processes actually interact.
        </p>
        <div class="claim-box" role="note" aria-label="Service boundary">
          <strong>We do not certify PCI compliance.</strong>
          We help verify the operating environment behind the compliance claim.
        </div>
      </section>

      <section aria-labelledby="who-title">
        <div class="section-grid">
          <div>
            <div class="section-label">01 / Fit</div>
            <h2 id="who-title">Who This Is For</h2>
          </div>
          <div class="content">
            <p>This review is for businesses that need a clearer view of payment-security exposure before signing forms, answering questionnaires, or assuming everything is handled by a processor.</p>
            <ul>
              <li>Accept card payments through POS, terminal, invoice, payment link, website, or phone.</li>
              <li>Are unsure what systems are in payment scope.</li>
              <li>Need help before completing a processor PCI questionnaire.</li>
              <li>Use Square, Stripe, Clover, PayPal, or another processor but do not fully understand remaining merchant responsibilities.</li>
              <li>Have payment devices sharing space with Wi-Fi, office computers, printers, cameras, or general business systems.</li>
              <li>Want a plain-language review before signing an SAQ or compliance attestation.</li>
            </ul>
          </div>
        </div>
      </section>

      <section aria-labelledby="review-title">
        <div class="section-grid">
          <div>
            <div class="section-label">02 / Review Areas</div>
            <h2 id="review-title">What We Review</h2>
          </div>
          <div class="cards">
            <article class="card">
              <h3>Payment Acceptance</h3>
              <p>Payment methods, card-data entry points, POS/payment-device setup, and whether payments occur in person, online, by invoice, or by phone.</p>
            </article>
            <article class="card">
              <h3>Network & Device Exposure</h3>
              <p>Network segmentation, Wi-Fi/payment exposure, device placement, admin access, vendor access, and whether normal business systems can reach payment systems.</p>
            </article>
            <article class="card">
              <h3>Stored Card-Data Risk</h3>
              <p>Possible card data in email, paper forms, call recordings, spreadsheets, logs, screenshots, CRMs, tickets, reports, or backups.</p>
            </article>
            <article class="card">
              <h3>Software & Vendor Responsibility</h3>
              <p>Hosted checkout, redirects, payment pages, payment software, third-party responsibility mapping, and evidence readiness for SAQ, AOC, processor review, or assessor review.</p>
            </article>
          </div>
        </div>
      </section>

      <section aria-labelledby="deliverable-title">
        <div class="section-grid">
          <div>
            <div class="section-label">03 / Deliverable</div>
            <h2 id="deliverable-title">Payment Security Scope Summary</h2>
          </div>
          <div class="deliverable content">
            <p>You receive a plain-language Payment Security Scope Summary that identifies:</p>
            <ul>
              <li>How payments are accepted.</li>
              <li>Where card data may enter or appear.</li>
              <li>Which systems may be in or near PCI scope.</li>
              <li>Whether segmentation appears necessary.</li>
              <li>Where business practices create exposure.</li>
              <li>What documentation is missing.</li>
              <li>Which gaps deserve owner attention.</li>
              <li>What evidence should be gathered before completing processor compliance forms.</li>
            </ul>
          </div>
        </div>
      </section>

      <section aria-labelledby="boundary-title">
        <div class="section-grid">
          <div>
            <div class="section-label">04 / Boundary</div>
            <h2 id="boundary-title">What This Is Not</h2>
          </div>
          <div class="boundary content">
            <p>
              CertumCore does not certify PCI compliance, act as a QSA, payment brand, acquirer, or governing authority, or guarantee validation results.
            </p>
            <p>
              The business owner remains responsible for its own PCI compliance and any formal attestation.
            </p>
            <p>
              CertumCore helps the business understand, document, and improve the operating reality before compliance forms are completed.
            </p>
          </div>
        </div>
      </section>

      <section aria-labelledby="cta-title">
        <div class="cta">
          <div>
            <h2 id="cta-title">Request Payment Security Scope Review</h2>
            <p>
              Send a basic description of how your business accepts card payments, including processor, POS, payment devices, online checkout, and whether payments occur by phone, invoice, website, or in person.
            </p>
          </div>
          <a class="button" href="mailto:support@certumcore.com?subject=Payment%20Security%20Scope%20Review&body=Hello%20CertumCore%2C%0A%0AI%20would%20like%20to%20request%20a%20Payment%20Security%20Scope%20Review.%0A%0ABusiness%20name%3A%0APayment%20processor%28s%29%3A%0APOS%20or%20terminal%20used%3A%0AHow%20payments%20are%20accepted%20%28in-person%2C%20phone%2C%20invoice%2C%20website%2C%20payment%20link%29%3A%0AAny%20known%20PCI%20questionnaire%20or%20processor%20request%3A%0A%0AThank%20you.">Request Review</a>
        </div>
        <p class="fine-print">Suggested URL: /pci-readiness.html</p>
      </section>
    </div>
  </main>

  <footer>
    <div class="page">
      <span>© 2026 CertumCore LLC. All rights reserved.</span>
      <span>Sacramento, California · Expected vs Actual — Verified</span>
    </div>
  </footer>
</body>
</html>


index.html
File

sitemap.xml
File

pci-readiness.html
File
what other pages need updated and wired to this new page?  I already added the google ad tag at top of pci-readiness page 

Thought for a second
You have one extra divider and you’re missing a divider before Privacy Policy.

Use this clean version:

<div class="footer-links">
  <a href="/payment-operations-review.html">Payment Review</a>
  <span class="footer-divider">|</span>

  <a href="/processor-statement-review.html">Processor Statements</a>
  <span class="footer-divider">|</span>

  <a href="/monthly-payment-monitoring.html">Monitoring</a>
  <span class="footer-divider">|</span>

  <a href="/pci-readiness.html">PCI Readiness</a>
  <span class="footer-divider">|</span>

  <a href="/privacy-policy.html">Privacy Policy</a>
  <span class="footer-divider">|</span>

  <a href="/security-policy.html">Security Policy</a>
  <span class="footer-divider">|</span>

  <a href="/refund-policy.html">Refund Policy</a>
  <span class="footer-divider">|</span>

  <a href="/terms-of-service.html">Terms of Service</a>
</div>
The mistake was here:

<span class="footer-divider">|</span>
<span class="footer-divider">|</span>
<a href="/pci-readiness.html">PCI Readiness</a>
<a href="/privacy-policy.html">Privacy Policy</a>
That creates || before PCI and no separator between PCI and Privacy.


<p>Sacramento, California</p>

    <div class="footer-links">
  <a href="/payment-operations-review.html">Payment Review</a>
  <span class="footer-divider">|</span>

  <a href="/processor-statement-review.html">Processor Statements</a>
  <span class="footer-divider">|</span>

  <a href="/monthly-payment-monitoring.html">Monitoring</a>
  <span class="footer-divider">|</span>

  <a href="/pci-readiness.html">PCI Readiness</a>
  <span class="footer-divider">|</span>

  <a href="/privacy-policy.html">Privacy Policy</a>
  <span class="footer-divider">|</span>

  <a href="/security-policy.html">Security Policy</a>
  <span class="footer-divider">|</span>

  <a href="/refund-policy.html">Refund Policy</a>
  <span class="footer-divider">|</span>

  <a href="/terms-of-service.html">Terms of Service</a>
</div>

Thought for a second
Yes — that footer block is now clean.

One tiny formatting note: indent the inner links for readability, but functionally you’re good.

<p>Sacramento, California</p>

<div class="footer-links">
  <a href="/payment-operations-review.html">Payment Review</a>
  <span class="footer-divider">|</span>

  <a href="/processor-statement-review.html">Processor Statements</a>
  <span class="footer-divider">|</span>

  <a href="/monthly-payment-monitoring.html">Monitoring</a>
  <span class="footer-divider">|</span>

  <a href="/pci-readiness.html">PCI Readiness</a>
  <span class="footer-divider">|</span>

  <a href="/privacy-policy.html">Privacy Policy</a>
  <span class="footer-divider">|</span>

  <a href="/security-policy.html">Security Policy</a>
  <span class="footer-divider">|</span>

  <a href="/refund-policy.html">Refund Policy</a>
  <span class="footer-divider">|</span>

  <a href="/terms-of-service.html">Terms of Service</a>
</div>
No duplicate divider, no missing separator, and the PCI link is wired correctly.



pci-readiness.html
File

Thought for 5s
The uploaded pci-readiness.html is close, but it still needs these fixes:

1. Fix broken nav links
Current page has:

<a href="/services">Services</a>
<a href="/privacy.html">Privacy</a>
<a href="/security.html">Security</a>
Change to:

<a href="/#services">Services</a>
<a href="/privacy-policy.html">Privacy</a>
<a href="/security-policy.html">Security</a>
Your current uploaded page still shows the old /services, /privacy.html, and /security.html links. 


2. Remove this line before publishing
Near the bottom, you have:

<p class="fine-print">Suggested URL: /pci-readiness.html</p>
That was useful for us internally, but it should not be visible on the live website. Remove it.

3. Footer is too thin compared to the main site
Current PCI page footer only has:

<span>© 2026 CertumCore LLC. All rights reserved.</span>
<span>Sacramento, California · Expected vs Actual — Verified</span>
That works, but I’d wire it like your main site footer so users and Google can move between pages.

Use:

<footer>
  <div class="page">
    <div>
      <p>© 2026 CertumCore LLC. All rights reserved.</p>
      <p>Sacramento, California · Expected vs Actual — Verified</p>
    </div>

    <div class="footer-links">
      <a href="/">Home</a>
      <span class="footer-divider">|</span>
      <a href="/payment-operations-review.html">Payment Review</a>
      <span class="footer-divider">|</span>
      <a href="/processor-statement-review.html">Processor Statements</a>
      <span class="footer-divider">|</span>
      <a href="/monthly-payment-monitoring.html">Monitoring</a>
      <span class="footer-divider">|</span>
      <a href="/pci-readiness.html">PCI Readiness</a>
      <span class="footer-divider">|</span>
      <a href="/privacy-policy.html">Privacy Policy</a>
      <span class="footer-divider">|</span>
      <a href="/security-policy.html">Security Policy</a>
    </div>
  </div>
</footer>
4. Add footer-link CSS
Because this standalone page uses its own CSS, add this before the media query:

.footer-links {
  display: flex;
  flex-wrap: wrap;
  gap: 8px;
  align-items: center;
}

.footer-links a {
  text-decoration: none;
}

.footer-links a:hover,
.footer-links a:focus {
  text-decoration: underline;
}

.footer-divider {
  color: var(--muted);
}
5. Optional but smart: add canonical
Add this in the <head>:

<link rel="canonical" href="https://certumcore.com/pci-readiness.html" />
Bottom line: content is good, Google tag is there, but fix the nav links, remove the internal “Suggested URL” line, and wire the footer.



pci-readiness.html
File

sitemap.xml
File

index.html
File

readiness...regenerate fixed file 

Thought for 40s
Done — fixed and regenerated.

Download the corrected pci-readiness-fixed.html

I fixed the nested footer, corrected the nav links, added the canonical tag, removed the internal “Suggested URL” line, and added the footer-link CSS. Rename it to pci-readiness.html when you deploy it.





pci-readiness.html
File

sitemap.xml
File

index.html
File

Thought for 22s
Good. This upload is almost deploy-ready.

What is fixed now:

pci-readiness.html no longer has the nested footer problem.

pci-readiness.html has the canonical tag.

pci-readiness.html has the corrected nav links.

pci-readiness.html footer includes PCI Readiness and main service links. 


index.html now has PCI Readiness in the top nav and a PCI Readiness service card. 


sitemap.xml includes https://certumcore.com/pci-readiness.html.

One minor cleanup remains in pci-readiness.html: the .footer-links, .footer-links a, .footer-links a:hover, and .footer-divider CSS block appears twice. It will not break the page, but it is messy.

Delete the second duplicate block:

.footer-links {
  display: flex;
  flex-wrap: wrap;
  gap: 8px;
  align-items: center;
}

.footer-links a {
  text-decoration: none;
}

.footer-links a:hover,
.footer-links a:focus {
  text-decoration: underline;
}

.footer-divider {
  color: var(--muted);
}
Also, your index.html footer still needs the PCI Readiness link added in the footer area. The top nav and service card are good, but the footer link block still skips from Monitoring to Privacy Policy. 


Use this footer block there:

<div class="footer-links">
  <a href="/payment-operations-review.html">Payment Review</a>
  <span class="footer-divider">|</span>
  <a href="/processor-statement-review.html">Processor Statements</a>
  <span class="footer-divider">|</span>
  <a href="/monthly-payment-monitoring.html">Monitoring</a>
  <span class="footer-divider">|</span>
  <a href="/pci-readiness.html">PCI Readiness</a>
  <span class="footer-divider">|</span>
  <a href="/privacy-policy.html">Privacy Policy</a>
  <span class="footer-divider">|</span>
  <a href="/security-policy.html">Security Policy</a>
  <span class="footer-divider">|</span>
  <a href="/refund-policy.html">Refund Policy</a>
  <span class="footer-divider">|</span>
  <a href="/terms-of-service.html">Terms of Service</a>
</div>
After that: deploy it.


you're going to need to regen the readiness file for that css mess 

Thought for 21s
Done — regenerated with the duplicate footer CSS removed.

Download the cleaned pci-readiness-clean.html

Rename it to pci-readiness.html when you deploy.

<!DOCTYPE html>
<html lang="en">
<head>
  <!-- Google tag (gtag.js) -->
  <script async src="https://www.googletagmanager.com/gtag/js?id=AW-18187105535"></script>
  <script>
    window.dataLayer = window.dataLayer || [];
    function gtag(){dataLayer.push(arguments);}
    gtag('js', new Date());
    gtag('config', 'AW-18187105535');
  </script>

  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
  <title>PCI Readiness Review | CertumCore</title>
  <meta name="description" content="CertumCore helps businesses understand payment-security exposure, PCI scope, payment-device risk, network segmentation, vendor responsibilities, and evidence readiness before completing PCI questionnaires or attestations." />
  <meta name="robots" content="index, follow" />
  
  <link rel="canonical" href="https://certumcore.com/pci-readiness.html" />

  <style>
    :root {
      --bg: #f4f1ec;
      --paper: #fffaf2;
      --ink: #1e1e1e;
      --muted: #5e5a53;
      --line: #2a2a2a;
      --accent: #3b475c;
      --accent-soft: #e8e3d8;
      --box: #ebe6dc;
    }

    * {
      box-sizing: border-box;
    }

    body {
      margin: 0;
      font-family: Georgia, "Times New Roman", serif;
      background: var(--bg);
      color: var(--ink);
      line-height: 1.55;
    }

    a {
      color: inherit;
    }

    .page {
      width: min(1120px, calc(100% - 32px));
      margin: 0 auto;
    }

    header {
      border-bottom: 2px solid var(--line);
      background: var(--paper);
    }

    .nav {
      display: flex;
      align-items: center;
      justify-content: space-between;
      gap: 24px;
      padding: 22px 0;
    }

    .brand {
      display: flex;
      flex-direction: column;
      letter-spacing: 0.02em;
      text-decoration: none;
    }

    .brand strong {
      font-size: 1.25rem;
      text-transform: uppercase;
      letter-spacing: 0.08em;
    }

    .brand span {
      color: var(--muted);
      font-size: 0.92rem;
    }

    .nav-links {
      display: flex;
      flex-wrap: wrap;
      gap: 16px;
      font-size: 0.95rem;
    }

    .nav-links a {
      text-decoration: none;
      border-bottom: 1px solid transparent;
    }

    .nav-links a:hover,
    .nav-links a:focus {
      border-bottom-color: var(--ink);
    }

    .hero {
      padding: 76px 0 54px;
      border-bottom: 1px solid var(--line);
    }

    .eyebrow {
      font-family: "Courier New", monospace;
      text-transform: uppercase;
      letter-spacing: 0.12em;
      font-size: 0.82rem;
      color: var(--accent);
      margin-bottom: 18px;
    }

    h1 {
      font-size: clamp(2.45rem, 6vw, 5.2rem);
      line-height: 0.98;
      margin: 0 0 24px;
      letter-spacing: -0.045em;
      max-width: 930px;
    }

    .hero p {
      max-width: 790px;
      font-size: clamp(1.12rem, 2vw, 1.38rem);
      color: var(--muted);
      margin: 0 0 18px;
    }

    .claim-box {
      margin-top: 34px;
      max-width: 820px;
      border: 2px solid var(--line);
      background: var(--box);
      padding: 24px;
      font-size: 1.12rem;
    }

    .claim-box strong {
      display: block;
      margin-bottom: 6px;
      font-size: 1.18rem;
    }

    main {
      padding: 46px 0 70px;
    }

    section {
      padding: 36px 0;
      border-bottom: 1px solid rgba(42, 42, 42, 0.35);
    }

    .section-grid {
      display: grid;
      grid-template-columns: 280px 1fr;
      gap: 44px;
      align-items: start;
    }

    h2 {
      margin: 0;
      font-size: 1.55rem;
      line-height: 1.15;
      letter-spacing: -0.02em;
    }

    .section-label {
      font-family: "Courier New", monospace;
      font-size: 0.82rem;
      color: var(--accent);
      text-transform: uppercase;
      letter-spacing: 0.1em;
      margin-bottom: 8px;
    }

    .content p {
      margin-top: 0;
      color: var(--muted);
      font-size: 1.05rem;
    }

    ul {
      margin: 0;
      padding-left: 20px;
    }

    li {
      margin: 9px 0;
      padding-left: 4px;
    }

    .cards {
      display: grid;
      grid-template-columns: repeat(2, minmax(0, 1fr));
      gap: 16px;
    }

    .card {
      border: 1px solid var(--line);
      background: var(--paper);
      padding: 20px;
      min-height: 100%;
    }

    .card h3 {
      margin: 0 0 10px;
      font-size: 1.08rem;
    }

    .card p {
      margin: 0;
      font-size: 0.98rem;
    }

    .deliverable {
      border: 2px solid var(--line);
      background: var(--paper);
      padding: 28px;
    }

    .boundary {
      border-left: 6px solid var(--accent);
      background: var(--accent-soft);
      padding: 24px;
    }

    .cta {
      display: grid;
      grid-template-columns: 1fr auto;
      gap: 28px;
      align-items: center;
      padding: 34px;
      border: 2px solid var(--line);
      background: var(--accent);
      color: #fff;
    }

    .cta h2,
    .cta p {
      color: #fff;
      margin: 0;
    }

    .cta p {
      margin-top: 10px;
      opacity: 0.92;
      max-width: 760px;
    }

    .button {
      display: inline-block;
      padding: 14px 20px;
      border: 2px solid #fff;
      text-decoration: none;
      font-weight: bold;
      background: #fff;
      color: var(--accent);
      white-space: nowrap;
    }

    footer {
      border-top: 2px solid var(--line);
      background: var(--paper);
      padding: 28px 0;
      color: var(--muted);
      font-size: 0.94rem;
    }

    footer .page {
      display: flex;
      justify-content: space-between;
      gap: 24px;
      flex-wrap: wrap;
    }

    footer p {
      margin: 0 0 6px;
    }

    .footer-links {
      display: flex;
      flex-wrap: wrap;
      gap: 8px;
      align-items: center;
    }

    .footer-links a {
      text-decoration: none;
    }

    .footer-links a:hover,
    .footer-links a:focus {
      text-decoration: underline;
    }

    .footer-divider {
      color: var(--muted);
    }


    @media (max-width: 800px) {
      .nav {
        align-items: flex-start;
        flex-direction: column;
      }

      .section-grid,
      .cta {
        grid-template-columns: 1fr;
      }

      .cards {
        grid-template-columns: 1fr;
      }

      .hero {
        padding-top: 52px;
      }

      .button {
        text-align: center;
      }
    }
  </style>
</head>
<body>
  <header>
    <div class="page nav">
      <a class="brand" href="/" aria-label="CertumCore Home">
        <strong>CertumCore</strong>
        <span>Expected vs Actual — Verified</span>
      </a>
      <nav class="nav-links" aria-label="Primary navigation">
        <a href="/">Home</a>
        <a href="/#services">Services</a>
        <a href="/privacy-policy.html">Privacy</a>
        <a href="/security-policy.html">Security</a>
        <a href="mailto:support@certumcore.com?subject=Payment%20Security%20Scope%20Review">Contact</a>
      </nav>
    </div>
  </header>

  <main>
    <div class="page">
      <section class="hero" aria-labelledby="hero-title">
        <div class="eyebrow">PCI Readiness / Payment Security Scope Review</div>
        <h1 id="hero-title">Payment Security Scope Review</h1>
        <p>
          Before completing PCI questionnaires or assuming your processor has everything covered, CertumCore helps identify how card data, payment devices, networks, vendors, and business processes actually interact.
        </p>
        <div class="claim-box" role="note" aria-label="Service boundary">
          <strong>We do not certify PCI compliance.</strong>
          We help verify the operating environment behind the compliance claim.
        </div>
      </section>

      <section aria-labelledby="who-title">
        <div class="section-grid">
          <div>
            <div class="section-label">01 / Fit</div>
            <h2 id="who-title">Who This Is For</h2>
          </div>
          <div class="content">
            <p>This review is for businesses that need a clearer view of payment-security exposure before signing forms, answering questionnaires, or assuming everything is handled by a processor.</p>
            <ul>
              <li>Accept card payments through POS, terminal, invoice, payment link, website, or phone.</li>
              <li>Are unsure what systems are in payment scope.</li>
              <li>Need help before completing a processor PCI questionnaire.</li>
              <li>Use Square, Stripe, Clover, PayPal, or another processor but do not fully understand remaining merchant responsibilities.</li>
              <li>Have payment devices sharing space with Wi-Fi, office computers, printers, cameras, or general business systems.</li>
              <li>Want a plain-language review before signing an SAQ or compliance attestation.</li>
            </ul>
          </div>
        </div>
      </section>

      <section aria-labelledby="review-title">
        <div class="section-grid">
          <div>
            <div class="section-label">02 / Review Areas</div>
            <h2 id="review-title">What We Review</h2>
          </div>
          <div class="cards">
            <article class="card">
              <h3>Payment Acceptance</h3>
              <p>Payment methods, card-data entry points, POS/payment-device setup, and whether payments occur in person, online, by invoice, or by phone.</p>
            </article>
            <article class="card">
              <h3>Network & Device Exposure</h3>
              <p>Network segmentation, Wi-Fi/payment exposure, device placement, admin access, vendor access, and whether normal business systems can reach payment systems.</p>
            </article>
            <article class="card">
              <h3>Stored Card-Data Risk</h3>
              <p>Possible card data in email, paper forms, call recordings, spreadsheets, logs, screenshots, CRMs, tickets, reports, or backups.</p>
            </article>
            <article class="card">
              <h3>Software & Vendor Responsibility</h3>
              <p>Hosted checkout, redirects, payment pages, payment software, third-party responsibility mapping, and evidence readiness for SAQ, AOC, processor review, or assessor review.</p>
            </article>
          </div>
        </div>
      </section>

      <section aria-labelledby="deliverable-title">
        <div class="section-grid">
          <div>
            <div class="section-label">03 / Deliverable</div>
            <h2 id="deliverable-title">Payment Security Scope Summary</h2>
          </div>
          <div class="deliverable content">
            <p>You receive a plain-language Payment Security Scope Summary that identifies:</p>
            <ul>
              <li>How payments are accepted.</li>
              <li>Where card data may enter or appear.</li>
              <li>Which systems may be in or near PCI scope.</li>
              <li>Whether segmentation appears necessary.</li>
              <li>Where business practices create exposure.</li>
              <li>What documentation is missing.</li>
              <li>Which gaps deserve owner attention.</li>
              <li>What evidence should be gathered before completing processor compliance forms.</li>
            </ul>
          </div>
        </div>
      </section>

      <section aria-labelledby="boundary-title">
        <div class="section-grid">
          <div>
            <div class="section-label">04 / Boundary</div>
            <h2 id="boundary-title">What This Is Not</h2>
          </div>
          <div class="boundary content">
            <p>
              CertumCore does not certify PCI compliance, act as a QSA, payment brand, acquirer, or governing authority, or guarantee validation results.
            </p>
            <p>
              The business owner remains responsible for its own PCI compliance and any formal attestation.
            </p>
            <p>
              CertumCore helps the business understand, document, and improve the operating reality before compliance forms are completed.
            </p>
          </div>
        </div>
      </section>

      <section aria-labelledby="cta-title">
        <div class="cta">
          <div>
            <h2 id="cta-title">Request Payment Security Scope Review</h2>
            <p>
              Send a basic description of how your business accepts card payments, including processor, POS, payment devices, online checkout, and whether payments occur by phone, invoice, website, or in person.
            </p>
          </div>
          <a class="button" href="mailto:support@certumcore.com?subject=Payment%20Security%20Scope%20Review&body=Hello%20CertumCore%2C%0A%0AI%20would%20like%20to%20request%20a%20Payment%20Security%20Scope%20Review.%0A%0ABusiness%20name%3A%0APayment%20processor%28s%29%3A%0APOS%20or%20terminal%20used%3A%0AHow%20payments%20are%20accepted%20%28in-person%2C%20phone%2C%20invoice%2C%20website%2C%20payment%20link%29%3A%0AAny%20known%20PCI%20questionnaire%20or%20processor%20request%3A%0A%0AThank%20you.">Request Review</a>
        </div>
      </section>
    </div>
  </main>

  <footer class="site-footer">
  <div class="container">
    <p>CertumCore LLC — Payment Operations Review</p>
    <p>Expected vs Actual — Verified</p>
    <p>Sacramento, California</p>

    <div class="footer-links">
      <a href="/payment-operations-review.html">Payment Review</a>
      <span class="footer-divider">|</span>

      <a href="/processor-statement-review.html">Processor Statements</a>
      <span class="footer-divider">|</span>

      <a href="/monthly-payment-monitoring.html">Monitoring</a>
      <span class="footer-divider">|</span>

      <a href="/pci-readiness.html">PCI Readiness</a>
      <span class="footer-divider">|</span>

      <a href="/privacy-policy.html">Privacy Policy</a>
      <span class="footer-divider">|</span>

      <a href="/security-policy.html">Security Policy</a>
      <span class="footer-divider">|</span>

      <a href="/refund-policy.html">Refund Policy</a>
      <span class="footer-divider">|</span>

      <a href="/terms-of-service.html">Terms of Service</a>
    </div>

    <p class="small">
      If you have difficulty using the website, email
      <a href="mailto:support@certumcore.com">support@certumcore.com</a>
      and CertumCore will provide an alternate submission path.
    </p>

    <p class="small">Last updated: May 2026</p>
  </div>
</footer>
</body>
</html>