The B2C Retail Stack
PCI Scope-Minimized, POS-Hardened, Disclosure-Ready
A documented, deployable security architecture for consumer-facing businesses. Designed to shrink your PCI DSS scope, isolate your point-of-sale, segment your guest Wi-Fi from your business network, classify customer data by retention obligation, and stand up a state-by-state breach disclosure runbook before you need it. This is the deliverable side of our B2C practice. For the buyer-side context (industries, threats, regulators, scenarios), see B2C Cybersecurity for Raleigh Consumer Businesses.
What Sits Inside a Petronella B2C Retail Stack
Every layer is chosen to do two things at once: cut your PCI scope and produce the audit evidence you will need when a processor, an insurer, a partner, or an attorney asks. No stack component exists for vibes; each maps to a control, a regulator's question, or a recoverable failure mode.
Layer 1: Payment Capture and Tokenization
Card data never lands in your environment in clear form. Hosted payment fields, P2PE-validated terminals, processor-issued tokens, and back-office systems that hold the token rather than the PAN.
Stripe Elements,Square Hosted Checkout,Toast Paymentsas integration targets- P2PE-validated PIN pads where card-present
- Vaulted token references in CRM, ERP and email systems
Layer 2: POS Endpoint Hardening
Each terminal is a controlled kiosk: app allow-listing, MFA at admin login, EDR sensor, screen-lock policy, blocked browsing, denied USB unless approved, scheduled patch windows that respect operating hours.
- Dedicated user accounts per shift, no shared logins
- Hardware-bound device identity for VLAN admission
- Local cache encrypted, off-device backups
Layer 3: Network Segmentation
Three logical networks at minimum: a POS-only segment for terminals and payment infrastructure, a corporate segment for office workstations and back-office tools, and a guest segment for customer Wi-Fi and untrusted devices. Cross-segment traffic is explicit, logged, and minimized.
- VLAN per role, not per device
- Stateful firewall rules between POS, corp and guest
- SSID separation, client isolation on guest, captive portal logging
Layer 4: Identity and Access
One identity provider in front of the SaaS sprawl. MFA on every admin surface, including processor portals, e-commerce admin, email service provider, booking platform, and CRM. Documented joiner-mover-leaver workflow tied to Workday or your payroll system.
- SSO via
Microsoft Entra IDorGoogle Workspace - Conditional access policies tied to device posture
- Privileged-account vault with rotation and check-out
Layer 5: Customer Data Plane
Your CRM, e-commerce database, booking platform, marketing automation and analytics warehouse are inventoried, classified, and tied to a retention schedule. Sensitive elements (DOB, SSN, government ID, payment vault references) are field-level encrypted and access-logged.
- Data inventory across SaaS and self-hosted
- Field-level encryption for sensitive PII columns
- Retention-driven purges feed audit log
Layer 6: Detection, Logging and Response
Endpoint EDR feeds a managed SIEM. POS, firewall, identity provider, and e-commerce admin events all land in the same store with retention sized for incident investigation, not just operational debugging. Detections are tuned for B2C-specific patterns.
- Card-checkout anomaly detection on the e-commerce front-end
- Credential-stuffing detection at the customer login
- POS off-hours admin login alerting
Cutting the PCI DSS Footprint Down to What You Can Actually Defend
PCI DSS does not get smaller because your business is small. It gets smaller because your architecture forces it to. The Petronella scope-minimization pattern is built around the principle that any system that does not need to see, store, process or transmit cardholder data should not be allowed to.
The mainstream approach for Triangle B2C merchants is SAQ A or SAQ A-EP, which both depend on outsourcing cardholder data handling to a validated third party (your processor, gateway, or hosted payment provider). The merchant's burden then shrinks to securing the redirect, the iframe, the script supply chain, and the back-office systems that touch order metadata and tokens.
For card-present environments, the equivalent move is to standardize on P2PE-validated terminals so card data is encrypted by the device hardware before the merchant network ever sees it. Combined with strict POS network isolation, this can reduce your in-scope systems from "every machine in the building" to "the terminal hardware and its management plane."
The Working Architecture
A typical Triangle B2C deployment looks like this in practice. A dedicated POS VLAN carries traffic only from validated terminals to the processor. The corporate VLAN carries office workstations, back-office reporting systems, and the e-commerce admin browser sessions. The guest VLAN carries customer Wi-Fi and is firewall-isolated from both. The e-commerce environment is hosted by the platform vendor (Shopify, BigCommerce, WooCommerce-managed) with the merchant operating only the admin surface, the storefront content, and the script supply chain.
Within that architecture, the merchant's PCI evidence stack reduces to a defensible list: the network diagram, the segmentation evidence, the storefront script inventory, the iframe configuration, the SAQ submission, the quarterly external scan (where required), and the change-management log. That is a stack a small operator can actually maintain without a dedicated compliance hire.
Common Scope-Bloat Mistakes We Untangle
Most B2C scope problems come from the same handful of choices: routing the POS through the same flat network as office laptops; pasting card numbers into a CRM "notes" field; emailing receipts that contain full PANs; using a shared admin password between the processor portal and the e-commerce backend; running a custom checkout that captures the card on the merchant's own server instead of through a hosted field. Every one of these collapses your SAQ tier and explodes your evidence requirements. Each one has a clean fix that does not break operations.
The POS Hardening Checklist We Apply to Every Triangle Deployment
Whether you are running Toast on iPads, Square Register on dedicated hardware, Clover Mini, Aloha terminals, or a Windows-based legacy system, the same baseline controls apply. The implementation differs; the control intent does not.
| Control Area | Baseline Configuration | Evidence Captured |
|---|---|---|
| Application Control | Allow-list of approved POS, payment, and management apps. Block all others by default. | app-allowlist.policy.json |
| Identity | Per-shift user accounts. Manager PIN required for refunds, voids, no-sale. No shared logins. | Audit log export weekly |
| Endpoint Detection | EDR agent with verified daily check-in. Tamper protection enabled. | EDR enrollment report |
| Patch Cadence | OS and POS app patches applied within 7 days of vendor release. Reboot windows scheduled outside trading hours. | Patch compliance dashboard |
| Network Posture | POS terminal joined to POS VLAN only. No guest Wi-Fi. No internet browsing. | Switch port mapping export |
| Removable Media | USB ports blocked or restricted to approved devices (receipt printers, scanners). | Device control policy |
| Remote Support | Remote-support tool restricted to single named platform with MFA. No standing remote-control software. | Remote-tool inventory |
| Screen Lock | Auto-lock at 5 minutes idle. Manager-PIN unlock required. | GPO or MDM screenshot |
| Local Storage | No local cache of cardholder data. Receipts and reports stored centrally. | Data flow diagram |
| Backup | Off-device, off-network backup of POS configuration, menu, and reporting data. | Backup test log |
Customer Wi-Fi vs Business Wi-Fi: A Pattern That Actually Holds Under Audit
"We have a separate guest network" is the most common verbal control we hear, and the most commonly misconfigured one we find. The pattern below is how we deploy retail Wi-Fi so that the guest network is genuinely isolated from POS and back-office traffic, not just labeled differently.
The reference architecture uses three SSIDs mapped to three VLANs at minimum. retail-pos is reserved for payment terminals, with port-level admission control tied to known MAC addresses or 802.1X certificates and no internet routing beyond the processor's destinations. retail-corp carries office laptops, back-office workstations, and printers, with full internet access through a filtering proxy and EDR-enforced device posture. retail-guest carries customer phones, laptops, and any vendor or contractor device, with client isolation enforced at the access point so guest devices cannot see each other or any other VLAN.
The corporate-to-guest firewall rule is deny-by-default with a small set of explicit allows for shared services such as a printer (often inadvisable) or a captive-portal login system. The POS VLAN has no inbound or outbound rule that touches guest at all. Guest internet egress is inspected by a content filter that blocks known malware, phishing, and credential-harvesting destinations, primarily as a customer-experience and brand-safety measure.
Wi-Fi Hardware We See Working
For most Triangle B2C deployments, we work with whatever the operator already has if it can do real VLAN tagging and per-SSID policy. UniFi, Meraki, Aruba Instant On, Fortinet FortiAP, and Cisco Business series all work in this pattern. We do not deploy consumer-grade access points behind a single flat network, regardless of brand. A converted home router with a "guest network" toggle does not give you defensible isolation.
Captive Portal and Logging
The guest captive portal optionally captures a customer email address (with clear consent disclosure) for marketing reuse. More importantly, it logs the device MAC and connection time, which is valuable evidence in two scenarios: a fraud investigation that needs to confirm a customer was on premises at a given time, and a regulatory subpoena tied to a specific session. That log retention is documented in your privacy policy and bounded by the same retention schedule as other customer data.
Classification and Retention Policy: The Decision Layer Most B2C Stacks Skip
A classification policy answers two questions per data element: how sensitive is it, and how long are we obligated to keep it? Without those answers, your e-commerce database, your CRM, your booking platform, and your email service provider quietly accumulate years of liability. This is the layer that makes a breach response defensible later.
| Data Class | Examples | Sensitivity | Default Retention |
|---|---|---|---|
| Public Marketing | Marketing opt-in email, name, postal address | Low | Until opt-out + 30 days |
| Transactional Customer | Order history, shipping address, customer support thread | Medium | 7 years (tax / chargeback) |
| Payment Reference | Processor token, last-4, expiration, customer billing address | High | While account is active |
| Loyalty / Behavioral | Points balance, visit history, preferences, browsing behavior | Medium | 3 years inactivity |
| Sensitive PII | DOB, SSN (auto / brokerage / cash health), driver's license, photo ID | Critical | Statutory minimum, encrypted at rest |
| Health and Wellness | Symptoms, treatment notes, intake forms (cash-pay clinics) | Critical | State medical records minimum |
| Wi-Fi Captive Portal | MAC, connection time, optional email | Low | 90 days |
| CCTV / Security Footage | Indoor and outdoor camera feeds | Medium | 30 days unless flagged |
The retention values above are starting points, not legal advice. Your final schedule depends on your specific state(s), industry overlays (HIPAA, FTC Safeguards, state insurance and brokerage rules), and your insurance carrier's recommendations. Petronella runs the technical implementation; we coordinate with your existing counsel or refer one of the breach attorneys we have worked with locally.
The real value of this layer shows up during a consumer rights request, an FTC inquiry, or a breach. When a CCPA request lands, you can answer it in days because your data inventory is current. When a regulator asks why a 2018 order is still in your CRM, you have a documented retention exception or a remediation log. When a breach is scoped, your impact set is bounded by your classification, not by "everything in the database."
A State-by-State Notification Runbook You Will Be Glad You Wrote Cold
When a breach is suspected, the runbook below is what your team executes. It is documented, dry-run tested, and stored both digitally (in your incident response repository) and physically (in a sealed envelope at each location). Writing it during an incident is too late.
STEP 1Detection and Initial Triage (Hour 0 to 4)
The first four hours determine whether this incident is contained or compounding, and whether your evidence is preserved or polluted. Do not delete anything. Do not announce anything publicly.
- Confirm the indicator: log entry, processor letter, customer report, vendor alert
- Snapshot affected systems before remediation actions to preserve forensic state
- Pull initial scope: which systems, which data classes, what time window
- Notify the documented decision-maker (owner, GM, or designated executive)
- Open the incident ticket with timestamps for every action taken
STEP 2Containment and Evidence Preservation (Hour 4 to 24)
Stop the bleeding without destroying the audit trail. Containment actions are documented and reversible.
- Isolate affected endpoints from the network (do not power off, preserve memory state)
- Rotate exposed credentials on the affected systems
- Engage breach counsel to maintain attorney-client privilege over forensic findings
- Engage cyber insurance carrier per policy notification window (often 24-72 hours)
- Preserve logs from all involved systems for the legally required retention period
STEP 3Scoping and Forensic Analysis (Day 1 to 14)
Determine exactly what data was accessed, by whom, and for how long. The defensibility of every later notification depends on this stage.
- Forensic image of affected systems for chain-of-custody preservation
- Log correlation across endpoint, network, identity provider, and SaaS audit logs
- Identification of impacted records by data class
- Written interim findings memo to counsel
- If card data is in scope, processor and card brand notification per their playbook
STEP 4Notification (Day 14 to 60, depending on jurisdiction)
Each affected jurisdiction has its own notification timeline, content rules, and recipient list. The runbook tracks them as a matrix.
- NC GS 75-65: written notice to affected NC residents and to the NC Attorney General
- Other states: per their respective breach notification statutes (CCPA, CCRA, NY SHIELD, etc.)
- Substitute notice via website, statewide media, or email if thresholds are met
- Credit monitoring offer where law or carrier requires it
- Customer-facing communications coordinated with PR if scope warrants
STEP 5Remediation and Post-Incident Review (Day 30 to 90)
Close the gaps that allowed the incident, document what changed, and pre-position for the inevitable insurance, processor, and (sometimes) regulator follow-up.
- Root-cause analysis written and reviewed
- Control changes implemented and tested
- Tabletop exercise scheduled within 90 days
- Insurance and processor follow-up packets prepared
- Lessons-learned added to the runbook for the next year's annual review
The Evidence Library That Comes Out of the Stack
Every Petronella B2C deployment leaves a documented evidence library. This is what your processor, your QSA, your insurance carrier, and your future breach attorney all want to see. Producing it during an audit is too late; it should be a maintained byproduct of your operations.
SAQ Submission Package
Current SAQ A or SAQ A-EP attestation, supporting evidence, and the 12-month working file showing how each control was operating during the attestation period.
Network Segmentation Diagram
Annotated diagram showing POS, corp and guest VLANs, the firewall rules between them, and the in-scope/out-of-scope boundary marked clearly.
POS Hardening Checklist Run
Per-terminal record of the 10-control hardening checklist, signed off quarterly with screenshots and config exports.
Data Inventory and Classification Map
System-by-system inventory of where each customer data class lives, who has access, retention rule, and last-reviewed date.
Consumer Rights Request Log
Tracked log of CCPA/CPRA, VCDPA and similar requests with date received, action taken, response sent, and record of any escalation.
Privacy Policy Version Log
Version-controlled history of your published privacy policy with effective dates, change rationale, and the technical changes that triggered each revision.
Identity Lifecycle Log
Joiner-mover-leaver log tied to payroll. Every account creation, role change, and termination tracked with timestamps and approver.
Patch and Vulnerability Records
Patch compliance dashboard exports plus quarterly vulnerability scan reports with remediation tracking.
Tabletop Exercise Records
Annual tabletop scenario, participants, decisions made, gaps identified, and follow-up actions with completion dates.
Disclosure Runbook with Last Tested Date
The state-by-state breach notification runbook above, with a record of when each section was last reviewed, dry-run tested, and updated for new state laws.
The Platforms the B2C Stack Plugs Into
Petronella does not push you onto a proprietary stack. The B2C reference architecture is platform-aware and integrates with the systems Triangle consumer businesses actually run today.
Payment and POS
Square, Stripe, Toast, Clover, Aloha, Lightspeed, Heartland, Shift4, and the major bank-issued processors. Where the operator already has a processor relationship, we work within it. Where there is room to choose, we will tell you which platforms make scope-minimization easier and which make it harder.
E-Commerce Platforms
Shopify, BigCommerce, WooCommerce on managed hosting, Magento (Adobe Commerce), Squarespace Commerce, and headless commerce stacks. The stack is built around the security model each platform actually exposes; we do not pretend Shopify needs the same WAF deployment a self-hosted Magento does.
Booking, CRM and Marketing
Vagaro, Mindbody, Mangomint, Booker, Acuity, Calendly, Square Appointments, HubSpot, Mailchimp, Klaviyo, ActiveCampaign, Constant Contact, Salesforce Essentials, Zoho. Each integration is reviewed for data flow, retention, and SSO/MFA support before the architecture diagram is finalized.
Identity, Email and Collaboration
Microsoft 365 with Entra ID, Google Workspace, and the password and secrets-management stack each operator prefers. We expect SSO into the operator's identity provider for every integration that supports it, and documented break-glass for the ones that do not.
Backup, Endpoint and Network
The right vendor for endpoint protection, backup, and network gear is whatever cleanly meets the controls above and is supportable by the operator and the Petronella team. We do not whitelabel a single SKU as the answer; we review what is in place, recommend changes only where the gap is real, and minimize change-noise on the operator's team.
Where the B2C Retail Stack Connects
Stack-Level Questions Operators Ask Before Signing Off
How long does a typical B2C Retail Stack deployment take?
For a single-location merchant on a hosted POS and a hosted e-commerce platform, the assessment, design and core deployment typically lands in 4 to 8 weeks. Multi-location and self-hosted environments stretch to 8 to 16 weeks. The disclosure runbook and audit evidence library are maintained continuously after that.
Do we have to replace our current POS?
Almost never. The stack is built around scope minimization with whatever processor and POS you have. Exceptions are environments running EOL Windows-based POS or non-validated payment hardware, where we will explain the trade-off and timeline rather than push a replacement.
How does this differ from a generic small-business managed services package?
A generic MSP package is sized to keep computers working. The B2C Retail Stack is sized to keep your card acceptance, your customer trust, and your regulatory posture intact. The two are complementary; we deliver both, but the architecture above is what you do not get by default with most general MSP relationships.
Will this satisfy our QSA / processor / insurance carrier?
The stack is designed against PCI DSS 4.0.1 SAQ A and SAQ A-EP requirements, against the FTC Safeguards Rule for in-scope merchant categories, and against the leading cyber insurance carrier control questionnaires. Any specific QSA or carrier may have additional asks; we close those as part of the engagement rather than send you back to procurement.
Can you operate this for us, or do we run it ourselves?
Both options exist. Some operators want the architecture documented, deployed, and handed off to their own internal team. Most want Petronella to operate the detection-and-response layer, the patch program, and the annual evidence cycle as a managed service. The stack is the same in either model.
Where does this stack sit in your overall practice?
This is the consumer-facing reference architecture in our small-business solutions practice. The buyer-side context (who we serve, threats, regulators, scenarios) lives on the B2C Cybersecurity identity page. The B2B sibling lives at Small Business B2B. Industry overlays (healthcare, finance, legal, federal) each have their own stack page under Solutions / Industries.
Walk Through the Stack With a Petronella Engineer
Bring your current POS, e-commerce, and Wi-Fi reality and a senior Petronella engineer will map it against the B2C Retail Stack on a free 30-minute call. You walk away with a one-page assessment of where you stand and what the realistic path forward looks like.