Regulatory Compliance Checklist

myowjaYOY/commerce

Generated by DocAgent — automated codebase documentation analysis. Based on analysis of 3 screens. Subject matter expert review is recommended before distribution.

April 19, 2026

Regulatory Compliance Checklist

Application: commerce Document Title: Regulatory Compliance Checklist Date: April 2026 Prepared By: DocAgent — Automated Codebase Documentation Analysis Frameworks Assessed: GDPR · CCPA/CPRA · SOC 2 Type II · PCI-DSS v4.0 · WCAG 2.1 Level AA Methodology: ISO/IEC 27001:2022 Annex A · NIST Cybersecurity Framework v2.0

1. Executive Summary

Generated by DocAgent — automated codebase documentation analysis. Subject matter expert review is recommended before distribution.

This checklist assesses five screens of the commerce application — Home (/), Search (/search), Search Detail (/search/[collection]), Item Detail (/[page]), and Product Detail (/product/[handle]) — against GDPR, CCPA/CPRA, SOC 2 Type II, PCI-DSS v4.0, and WCAG 2.1 Level AA requirements. The application is a Next.js/Shopify e-commerce storefront that is publicly accessible, handles no authentication on the assessed screens, and delegates all payment processing and data persistence to Shopify's hosted platform. Across 57 assessed requirements, the application is Compliant on 8, Partially Compliant on 14, Non-Compliant on 9, Cannot Assess on 21, and Not Applicable on 5. The overall compliance posture is Partially Compliant across all five frameworks, with the strongest documented posture in PCI-DSS (due to Shopify's hosted payment scope reduction) and the weakest in GDPR and CCPA/CPRA (due to near-total absence of documented consent, privacy notice, and data subject rights mechanisms).

The three highest-risk compliance gaps are: (1) Absence of documented consent management and legal basis for any data processing (GDPR Art. 6–7, CCPA §1798.100), which is a foundational requirement that cannot be deferred; (2) No documented privacy notice or "Do Not Sell" opt-out mechanism (GDPR Art. 13, CCPA §1798.120, SOC 2 P1.1), which creates direct regulatory exposure for a public-facing storefront; and (3) No documented logging, monitoring, or incident response capability (GDPR Art. 33, SOC 2 CC7.1–CC7.2, PCI-DSS Req 10), which prevents detection of and response to security events. The application has the strongest posture in PCI-DSS because payment card data processing is entirely delegated to Shopify's PCI-compliant infrastructure, and in WCAG 2.1 AA where several semantic HTML patterns are correctly implemented. The weakest posture is in GDPR and CCPA/CPRA, where the documentation provides almost no evidence of privacy controls, consent mechanisms, or data subject rights workflows.

This assessment is documentation-based and does not constitute a live audit, penetration test, or organizational policy review. Compliance status reflects what is documented in the five screen specifications provided; controls implemented in undocumented screens, shared layout components, middleware, infrastructure, or organizational procedures are outside the scope of this document and must be assessed separately. Many "Cannot Assess" findings reflect documentation gaps rather than confirmed non-compliance, and investigation with the responsible teams is required before treating those items as compliant or non-compliant.

2. Assessment Methodology

Approach

Documentation-based technical control assessment. Each requirement is evaluated against the technical implementation details described in the screen documentation provided. No live system testing, code execution, or organizational policy review was performed.

Frameworks

Control Mapping

Scope

This checklist covers 5 screen(s) of the commerce application:

Screen Route
Home /
Search /search
Search Detail /search/[collection]
Item Detail /[page]
Product Detail /product/[handle]

Screens, features, and components not included in the assessed documentation are outside the scope of this document. This includes but is not limited to: the site header/navbar, search input component, sort filter component, cart/checkout flow, account management screens, ThreeItemGrid, Carousel, Gallery, ProductDescription, Footer, ProductGridItems, Grid, Prose, GridTileImage, and the lib/shopify service layer.

⚠️ Several workflows documented in the assessed screens continue beyond the documented screens. The add-to-cart and checkout flow initiated from the Product Detail screen (/product/[handle]) via the ProductDescription component, and the cart management flow, are not covered in this document. Verify the complete purchase workflow with the development team before treating this as a comprehensive process description.

Limitations

Compliance Status Definitions

Status Definition Symbol
Compliant Documented controls fully satisfy the requirement ✅
Partially Compliant Some controls present but gaps exist ⚠️
Non-Compliant Required controls not documented or clearly missing ❌
Not Applicable Requirement does not apply to this application N/A
Cannot Assess Insufficient documentation to determine compliance ❓

3. Applicability Matrix

Framework Applicable Rationale
GDPR Likely The application is a public e-commerce storefront. If it serves EU/EEA residents — which is standard for Shopify-based stores unless geo-restricted — GDPR applies. The application processes URL query parameters (search terms) and serves product data. Whether cookies, analytics, or personal data are processed is not documented in the assessed screens but is standard for e-commerce applications.
CCPA/CPRA Likely The application is a public-facing e-commerce storefront. If the business meets CCPA thresholds (annual gross revenue >$25M, or buys/sells/receives/shares personal information of 100,000+ consumers/households, or derives 50%+ of revenue from selling personal information) and serves California residents, CCPA/CPRA applies. Shopify-based stores routinely collect personal information (browsing behavior, purchase history) that triggers CCPA obligations.
SOC 2 Likely The application is a SaaS-pattern e-commerce storefront handling customer browsing data and delegating payment/order data to Shopify. If the business provides services to other businesses or handles customer data on behalf of clients, SOC 2 is applicable. Even for direct-to-consumer stores, SOC 2 is increasingly expected by enterprise buyers and partners.
PCI-DSS Likely The application integrates with Shopify for commerce, which includes payment card processing. Even if Shopify handles all card data directly (reducing scope), the merchant is still a PCI-DSS entity and must comply with SAQ A or equivalent requirements. The assessed screens do not include checkout, but the application as a whole is in scope.
WCAG 2.1 AA Yes The application is a public-facing web application. WCAG 2.1 AA compliance is a legal requirement in many jurisdictions (ADA Title III in the US, EN 301 549 in the EU, AODA in Canada) and is a baseline expectation for any public-facing digital product.

4. GDPR Compliance Checklist

4.1 Principles (Article 5)

# Principle Requirement Status Evidence Gap Remediation
GD-001 Lawfulness Processing has valid legal basis (Art. 6) ❓ The assessed screens are read-only, publicly accessible product discovery pages. No personal data collection is documented in these screens. Search query strings (q parameter) are passed to Shopify's API but are not stored by the application. Whether the broader application (checkout, analytics, cookies) processes personal data under a valid legal basis is not documented. No legal basis is documented for any data processing. Whether processing occurs on these screens is unclear. [Not documented — WHO: DPO or legal counsel; WHAT: What personal data is processed by the application (including analytics, cookies, and Shopify data sharing), and what is the legal basis (Art. 6(1)(a)–(f)) for each processing activity?; WHERE: Insert in GD-001 Evidence column and GD-019 Records of Processing]
GD-002 Purpose Limitation Data used only for specified purposes ❓ Search query strings are passed to Shopify's Storefront API for product search only. No other data processing purposes are documented for the assessed screens. No documented purpose limitation policy. Whether Shopify or the application uses search queries or browsing data for additional purposes (analytics, personalization) is not documented. [Not documented — WHO: DPO and Shopify account owner; WHAT: Does Shopify process storefront query data for purposes beyond fulfilling the API request (e.g., Shopify analytics, advertising)? What are all processing purposes for data collected by this application?; WHERE: Insert in GD-002 Evidence column]
GD-003 Data Minimisation Only necessary data collected ⚠️ The assessed screens collect only URL query parameters (q, sort, [collection], [page], [handle]) necessary for product discovery. No forms, user accounts, or PII collection are present on these screens. The searchValue is passed directly to Shopify without storage. Data minimisation on the assessed screens appears reasonable, but the broader application (checkout, account creation, analytics/cookies) is not assessed. The hardcoded SEO description on the Home screen ("High-performance ecommerce store built with Next.js, Vercel, and Shopify.") suggests the application may not yet be production-configured, raising questions about what data collection is planned. Confirm that no analytics, session tracking, or cookie-based data collection occurs on these screens beyond what is documented. Assess checkout and account screens separately.
GD-004 Accuracy Data kept up to date ❓ Product data is fetched from Shopify at render time (server-side). Shopify is the system of record for product information. No user-submitted personal data is stored or displayed on the assessed screens. No user data accuracy mechanisms are documented because no user data is collected on these screens. Whether the broader application stores user data and provides correction mechanisms is not assessed. Assess account management and order history screens for data accuracy controls. Confirm with Shopify account owner that product data synchronisation is current.
GD-005 Storage Limitation Data not kept longer than necessary ❓ No data storage is documented on the assessed screens. Next.js server-side rendering fetches data at request time without persisting it. No cookies, localStorage, or sessionStorage are used on these screens. No retention policy is documented. Whether Next.js caching (configured in lib/shopify) stores personal data (e.g., search queries in cache keys) beyond necessary periods is not documented. [Not documented — WHO: Security lead and infrastructure team; WHAT: Does the Next.js fetch cache or any CDN layer store search query strings or other personal data? What is the cache TTL and retention policy?; WHERE: Insert in GD-005 Evidence column]
GD-006 Integrity & Confidentiality Appropriate security measures ⚠️ Shopify API credentials (SHOPIFY_STORE_DOMAIN, SHOPIFY_STOREFRONT_ACCESS_TOKEN) are documented as server-only environment variables, never exposed to the client bundle. React Server Components prevent API keys from being serialized to the client. JSX auto-escaping prevents XSS on rendered search terms. No transport security (HTTPS/TLS) configuration is documented. No server-side security hardening, WAF, or rate limiting is documented. The type-cast vulnerability in searchParams (documented in §17 of Search and Search Detail screens) represents a minor robustness gap. Document TLS configuration. Address the searchParams type-cast issue (see GD-016). Assess infrastructure security controls separately.
GD-007 Accountability Demonstrate compliance ❌ No compliance documentation, DPO designation, privacy policy, or data processing records are referenced in the assessed screens. No accountability mechanisms are documented. No privacy policy link is visible in the assessed screens (though it may exist in the Footer component, which is not fully documented). Appoint a DPO if required. Maintain records of processing activities (Art. 30). Implement a privacy policy accessible from all pages. Conduct and document a DPIA if high-risk processing occurs. (Organizational control — outside documentation scope for policy elements.)

4.2 Data Subject Rights (Articles 12–22)

# Right Article Status Evidence Gap Remediation
GD-008 Transparent Information Art. 12–13 ❌ The Item Detail screen (/[page]) is documented as capable of rendering Shopify-authored pages including "Privacy Policy" and "Terms of Service" via the Prose component. This is the only evidence of a potential privacy notice mechanism. No privacy notice is documented as being present or linked from the assessed screens. The Footer component (referenced on Home and Product Detail screens) may contain a privacy policy link, but its content is not documented. No evidence of Art. 13 disclosures (identity of controller, purposes, legal basis, retention periods, data subject rights) is present in the assessed documentation. Implement a GDPR-compliant privacy notice accessible from all pages. Ensure the Item Detail screen's privacy policy page contains all Art. 13 required disclosures. Verify the Footer contains a persistent link to the privacy policy.
GD-009 Right of Access Art. 15 ❌ No data subject access request (DSAR) mechanism is documented in any assessed screen. No mechanism for users to request access to their personal data is documented. Implement a DSAR submission mechanism (e.g., a contact form or dedicated privacy portal). Document the process for responding within 30 days. (Organizational control — outside documentation scope for process elements.)
GD-010 Right to Rectification Art. 16 ❌ No data correction mechanism is documented. No mechanism for users to correct inaccurate personal data is documented. Implement a rectification request mechanism. If Shopify manages customer accounts, verify Shopify's built-in account management supports rectification.
GD-011 Right to Erasure Art. 17 ❌ No data deletion mechanism is documented. No mechanism for users to request deletion of their personal data is documented. Implement an erasure request mechanism. Coordinate with Shopify on customer data deletion capabilities. (Organizational control — outside documentation scope for process elements.)
GD-012 Right to Restriction Art. 18 ❌ No processing restriction mechanism is documented. No mechanism for users to restrict processing of their personal data is documented. Implement a restriction request mechanism as part of a broader DSAR workflow.
GD-013 Data Portability Art. 20 ❌ No data export mechanism is documented. No mechanism for users to receive their personal data in a portable format is documented. Implement a data export mechanism for personal data processed under consent or contract. Verify Shopify's customer data export capabilities.
GD-014 Right to Object Art. 21 ❌ No objection mechanism is documented. No mechanism for users to object to processing (particularly for direct marketing or legitimate interests) is documented. Implement an objection mechanism, particularly if the application uses legitimate interests as a legal basis for any processing.
GD-015 Automated Decision-Making Art. 22 N/A The assessed screens perform no automated decision-making with legal or similarly significant effects. Product recommendations (getProductRecommendations) are presentational only and do not affect user rights or access. None identified for the assessed screens. No action required for the assessed screens. Reassess if personalisation or pricing algorithms with significant effects are introduced.

4.3 Security & Breach (Articles 32–34)

# Requirement Article Status Evidence Gap Remediation
GD-016 Security of Processing Art. 32 ⚠️ Shopify API credentials are documented as server-only environment variables (not exposed to client). React Server Components prevent credential leakage to the client bundle. JSX auto-escaping prevents XSS on search term rendering. The " entity is used as an additional escaping measure. JSON-LD is populated from Shopify API data (trusted source) via dangerouslySetInnerHTML on the Product Detail screen. No TLS/HTTPS configuration is documented. No WAF, rate limiting, DDoS protection, or server hardening is documented. The searchParams type-cast vulnerability (documented in §17 of Search and Search Detail screens) is a minor robustness gap. No error boundary or structured error handling is documented, meaning API failures may expose stack traces. No logging or monitoring is documented on any assessed screen. Document and verify TLS configuration. Address searchParams type-cast (use explicit property access with fallback). Implement structured error handling to prevent stack trace exposure. Implement logging and monitoring (see GD-017). (Organizational control — outside documentation scope for infrastructure elements.)
GD-017 Breach Notification Art. 33–34 ❌ No logging, monitoring, alerting, or incident response capability is documented in any assessed screen. All five screen specifications explicitly state that no error tracking service calls (Sentry, Datadog, etc.) are present. Without logging and monitoring, breach detection is not possible. No incident response procedure is documented. Implement application-level error tracking (e.g., Sentry, Datadog). Implement server-side access logging. Establish and document an incident response procedure with 72-hour DPA notification capability. (Organizational control — outside documentation scope for procedure elements.)

4.4 Data Processing (Articles 25–30, 35)

# Requirement Article Status Evidence Gap Remediation
GD-018 Privacy by Design/Default Art. 25 ⚠️ The assessed screens demonstrate several privacy-by-design characteristics: no authentication required for public product data, no PII collected on product discovery screens, Shopify API credentials are server-only, React Server Components prevent client-side data exposure, and the application uses the minimum URL parameters necessary for product discovery. No formal privacy-by-design process is documented. The searchParams type-cast issue (§17 of Search and Search Detail screens) represents a minor privacy-by-default gap (unexpected data shapes could cause unintended behavior). The broader application (checkout, analytics) is not assessed. Document the privacy-by-design approach. Address the searchParams type-cast issue. Conduct a privacy impact review of the checkout and account management flows.
GD-019 Records of Processing Art. 30 ❌ No records of processing activities (RoPA) are referenced in the assessed documentation. No RoPA is documented. Create and maintain a RoPA covering all processing activities, including Shopify as a data processor. (Organizational control — outside documentation scope.)
GD-020 DPIA Art. 35 ❓ No DPIA is referenced in the assessed documentation. The assessed screens handle only public product catalog data and do not appear to involve high-risk processing. Whether the broader application (checkout, customer accounts, analytics, profiling) requires a DPIA is not assessable from the provided documentation. [Not documented — WHO: DPO; WHAT: Has a DPIA been conducted for the application's processing activities, particularly checkout, customer account management, and any analytics or profiling? Does any processing meet the Art. 35 threshold (large-scale processing, systematic monitoring, sensitive data)?; WHERE: Insert in GD-020 Evidence column]

5. CCPA/CPRA Compliance Checklist

# Requirement Section Status Evidence Gap Remediation
CC-001 Right to Know §1798.100 ❌ The Item Detail screen can render a Shopify-authored "Privacy Policy" page via the Prose component. No other evidence of a "Right to Know" disclosure mechanism is documented. No documented mechanism for consumers to know what personal information is collected, used, disclosed, or sold. No privacy notice is confirmed to be present and accessible from all pages. Implement a CCPA-compliant privacy notice disclosing categories of personal information collected, purposes of use, and categories of third parties with whom information is shared. Ensure the notice is accessible from all pages (typically via footer link).
CC-002 Right to Delete §1798.105 ❌ No deletion request mechanism is documented in any assessed screen. No mechanism for consumers to request deletion of their personal information is documented. Implement a deletion request submission mechanism. Coordinate with Shopify on customer data deletion. Establish a 45-day response process. (Organizational control — outside documentation scope for process elements.)
CC-003 Right to Opt-Out of Sale/Sharing §1798.120 ❌ No "Do Not Sell or Share My Personal Information" link or opt-out mechanism is documented in any assessed screen. The Footer component is referenced on multiple screens but its content is not documented. No opt-out mechanism is documented. If the application shares consumer data with Shopify or third-party analytics providers, a "Do Not Sell or Share" link is required. Implement a "Do Not Sell or Share My Personal Information" link accessible from all pages (typically in the footer). Assess whether data sharing with Shopify, analytics providers, or advertising platforms constitutes "sale" or "sharing" under CPRA.
CC-004 Right to Non-Discrimination §1798.125 ❓ The assessed screens are publicly accessible with no authentication or pricing differentiation based on privacy choices. Whether the broader application (account management, loyalty programs, promotions) discriminates based on privacy choices is not assessable from the provided documentation. [Not documented — WHO: Legal counsel and product team; WHAT: Does the application offer different prices, quality of service, or benefits based on whether a consumer exercises their privacy rights?; WHERE: Insert in CC-004 Evidence column]
CC-005 Right to Correct §1798.106 (CPRA) ❌ No data correction mechanism is documented in any assessed screen. No mechanism for consumers to correct inaccurate personal information is documented. Implement a correction request mechanism. Verify Shopify's customer account management supports data correction.
CC-006 Right to Limit Sensitive PI §1798.121 (CPRA) ❓ No sensitive personal information is documented as being collected on the assessed screens. Whether the broader application (checkout, account creation) collects sensitive personal information (payment data, precise geolocation, account credentials) and whether a "Limit the Use of My Sensitive Personal Information" mechanism is required is not assessable from the provided documentation. [Not documented — WHO: Legal counsel and DPO; WHAT: Does the application collect sensitive personal information as defined by CPRA §1798.140(ae)? If so, is a "Limit the Use" mechanism required and implemented?; WHERE: Insert in CC-006 Evidence column]
CC-007 Privacy Notice §1798.100(b) ❌ The Item Detail screen can render a Shopify-authored privacy policy page. No evidence that a privacy notice is linked from all pages or contains CCPA-required disclosures. No CCPA-compliant privacy notice is confirmed to be present, accessible from all pages, and containing required disclosures (categories of PI collected, purposes, consumer rights, contact information). Implement a CCPA-compliant privacy notice. Ensure it is linked from all pages. Update annually or when practices change.
CC-008 Data Minimization §1798.100(c) (CPRA) ⚠️ The assessed screens collect only URL query parameters necessary for product discovery. No PII is collected on these screens. Search queries are passed to Shopify's API and not stored by the application. Data minimization on the assessed screens is reasonable. Whether the broader application (checkout, analytics, cookies) adheres to data minimization principles is not assessed. Conduct a data inventory of all personal information collected by the application and its third-party integrations. Confirm that collection is limited to what is reasonably necessary for disclosed purposes.
CC-009 Reasonable Security §1798.150 ⚠️ Shopify API credentials are server-only. React Server Components prevent credential leakage. JSX auto-escaping prevents XSS. No documented security testing, WAF, rate limiting, or infrastructure hardening. No logging or monitoring documented. The searchParams type-cast vulnerability is a minor gap. Implement and document reasonable security measures. Conduct regular security testing. Implement logging and monitoring. Address the searchParams type-cast issue. (Organizational control — outside documentation scope for policy elements.)
CC-010 Service Provider Controls §1798.140(ag) ❓ Shopify is the primary data processor/service provider. Shopify API credentials are used server-side. No documented data processing agreement (DPA) with Shopify or other service providers. Whether Shopify's standard merchant terms satisfy CCPA service provider requirements is not documented. [Not documented — WHO: Legal counsel; WHAT: Is there a CCPA-compliant service provider agreement with Shopify and any other third-party service providers (analytics, CDN, hosting)? Do those agreements prohibit the service provider from selling or using the data for their own purposes?; WHERE: Insert in CC-010 Evidence column]

6. SOC 2 Compliance Checklist

# Criterion Category Status Evidence Gap Remediation
SC-001 CC1.1 — Board Oversight Security ❓ No organizational governance documentation is present in the assessed screen specifications. Board-level oversight of security and compliance is an organizational control not visible in screen documentation. (Organizational control — outside documentation scope.) Verify with management that board-level oversight of security policies and risk management exists.
SC-002 CC5.1 — Logical Access Security ⚠️ The assessed screens are intentionally public with no authentication required. This is appropriate for a public e-commerce storefront. No admin or privileged access controls are documented for the assessed screens. No documentation of access controls for administrative functions, Shopify admin access, server/infrastructure access, or deployment pipelines. [Not documented — WHO: Security lead and DevOps team; WHAT: What access controls govern administrative access to the Shopify admin, deployment infrastructure, and server environment? Are least-privilege principles applied?; WHERE: Insert in SC-002 Evidence column]
SC-003 CC5.2 — Authentication Security ❓ No authentication is implemented on the assessed screens (appropriate for public product discovery). Authentication mechanisms for administrative users, deployment systems, and any authenticated customer flows are not documented in the assessed screens. [Not documented — WHO: Security lead; WHAT: What authentication mechanisms (MFA, SSO, password policies) are implemented for administrative access to the application infrastructure, Shopify admin, and any customer-facing authenticated flows?; WHERE: Insert in SC-003 Evidence column]
SC-004 CC6.1 — Encryption Security ⚠️ Shopify API credentials are documented as server-only environment variables, never exposed to the client bundle. React Server Components prevent serialization of secrets to the client. No data is stored locally by the assessed screens. No TLS/HTTPS configuration is documented. No encryption-at-rest documentation for any data stored by the application. Whether the Next.js cache stores any sensitive data in encrypted form is not documented. Document TLS configuration (verify HTTPS is enforced for all routes). Confirm Next.js cache and any server-side storage uses encryption at rest. (Inferred from Next.js/Vercel deployment pattern — verify against Vercel project settings and custom domain TLS configuration.)
SC-005 CC6.2 — Transmission Security Security ⚠️ All Shopify API calls are made server-side via lib/shopify. The Shopify Storefront API communicates over HTTPS (inferred from Shopify platform standards — verify against lib/shopify implementation). No client-to-server transmission of sensitive data occurs on the assessed screens. No explicit TLS version requirements or certificate management documentation. Whether the application enforces HTTPS for all client-server communication is not documented. (Inferred from Shopify platform standards — verify against lib/shopify HTTP client configuration and Vercel/hosting TLS settings.) Document TLS requirements and verify enforcement.
SC-006 CC6.3 — Change Management Security ❓ No change management process is documented in the assessed screen specifications. No documentation of code review, deployment approval, or change management processes. (Organizational control — outside documentation scope.) Verify with the development team that a formal change management process (code review, staging environment, deployment approval) exists.
SC-007 CC7.1 — Monitoring Security ❌ All five assessed screen specifications explicitly state that no error tracking service calls (Sentry, Datadog, etc.) or analytics event calls are present in the page components. No logging is documented at the page level. No application-level monitoring, logging, or alerting is documented. Anomaly detection and security event monitoring are not documented. Implement application-level error tracking (e.g., Sentry). Implement server-side access logging. Configure alerting for anomalous patterns. Verify whether monitoring exists at the infrastructure/CDN level (e.g., Vercel analytics, Cloudflare).
SC-008 CC7.2 — Incident Response Security ❌ No incident response capability is documented. No error boundaries, structured error handling, or escalation paths are documented in the assessed screens. No incident response plan, escalation procedure, or breach notification process is documented. (Organizational control — outside documentation scope.) Establish and document an incident response plan. Implement application-level error tracking to enable incident detection.
SC-009 CC8.1 — Risk Assessment Security ❓ No formal risk assessment is referenced in the assessed documentation. The §17 Known Issues sections of the Search, Search Detail, and Product Detail screens document specific technical risks (type-cast vulnerability, missing error boundaries, unsafe featuredImage access), which demonstrates some awareness of technical risk. No formal risk assessment process is documented. (Organizational control — outside documentation scope.) Verify that a formal risk assessment process exists and that identified technical risks (documented in §17 of screen specifications) are tracked in a risk register.
SC-010 A1.1 — Processing Integrity Availability ⚠️ The application uses Next.js server-side rendering with Shopify as the data source. Sort parameter fallback logic ensures the application always renders with a valid sort configuration even when invalid parameters are provided. The notFound() pattern ensures invalid routes render 404 pages rather than broken states. No SLA, uptime target, or availability monitoring is documented. No documented redundancy or failover for the Shopify API dependency. No error boundaries or graceful degradation for API failures are documented on the assessed screens. Document availability targets. Implement error boundaries and graceful degradation for Shopify API failures. Monitor Shopify API availability.
SC-011 A1.2 — Recovery Availability ❓ No backup, recovery, or business continuity documentation is present in the assessed screen specifications. No recovery time objective (RTO), recovery point objective (RPO), or disaster recovery plan is documented. (Organizational control — outside documentation scope.) Verify with infrastructure team that backup and recovery procedures exist for the application and its data.
SC-012 PI1.1 — Data Quality Processing Integrity ⚠️ Product data is fetched from Shopify at render time, ensuring data freshness at the point of display. The notFound() pattern prevents rendering of invalid/missing data. Sort parameter validation ensures only valid sort configurations are applied. The searchParams type-cast issue (§17 of Search and Search Detail screens) could cause incorrect data to be passed to the Shopify API. The page.updatedAt malformed date edge case (§10 of Item Detail screen) could render "Invalid Date" to users. The unsafe featuredImage access in Product Detail JSON-LD (§17) could cause a runtime error. Address the searchParams type-cast issue. Add a null guard for product.featuredImage in JSON-LD construction. Add input validation for page.updatedAt before date formatting.
SC-013 C1.1 — Data Classification Confidentiality ❓ No data classification scheme is documented. The assessed screens handle only public product catalog data, which would be classified as public/non-sensitive. No formal data classification policy is documented. Whether the broader application handles data requiring higher classification (customer PII, payment data) and whether those are classified appropriately is not assessable from the provided documentation. (Organizational control — outside documentation scope.) Establish a data classification policy. Verify that Shopify customer data (PII, order history) is classified and handled appropriately.
SC-014 C1.2 — Data Disposal Confidentiality ❓ No data disposal procedures are documented. The assessed screens do not store data persistently. Whether the application or its infrastructure retains logs, cache data, or other data that requires secure disposal is not documented. [Not documented — WHO: Infrastructure team and security lead; WHAT: What data does the application retain (logs, cache, session data), and what are the disposal procedures for that data?; WHERE: Insert in SC-014 Evidence column]
SC-015 P1.1 — Privacy Notice Privacy ❌ The Item Detail screen can render a Shopify-authored privacy policy page. No evidence that a privacy notice is linked from all pages or contains SOC 2 Privacy Criteria-required disclosures. No privacy notice confirmed to be present, accessible, and containing required disclosures about data collection, use, and sharing practices. Implement a privacy notice accessible from all pages. Ensure it covers all data collection and processing activities. Verify the Footer component contains a persistent privacy policy link.

7. PCI-DSS Compliance Checklist

Scope Note: The assessed screens (Home, Search, Search Detail, Item Detail, Product Detail) do not include checkout or payment processing flows. Payment card data handling is delegated to Shopify's hosted platform. The merchant's PCI-DSS scope is therefore significantly reduced (likely SAQ A eligible), but the merchant remains a PCI-DSS entity. Requirements below are assessed against the documented screens only. Infrastructure and organizational requirements are marked accordingly.

# Requirement PCI-DSS Req Status Evidence Gap Remediation
PC-001 Network Segmentation Req 1 ❓ No network architecture documentation is present in the assessed screen specifications. Network segmentation between the application and cardholder data environment is not documented. (Organizational control — outside documentation scope.) Verify with infrastructure team that network segmentation is implemented. If Shopify hosts all payment processing, confirm SAQ A scope reduction with a QSA.
PC-002 Secure Configuration Req 2 ❓ No server or system configuration documentation is present in the assessed screen specifications. Shopify API credentials are documented as server-only environment variables. System hardening and secure configuration baselines are not documented. (Organizational control — outside documentation scope.) Verify with infrastructure team that secure configuration baselines are applied to all system components.
PC-003 Protect Stored Data Req 3 ✅ The assessed screens store no cardholder data. No localStorage, sessionStorage, cookies, or database writes are documented on any assessed screen. All payment processing is delegated to Shopify's hosted platform. Search queries, sort parameters, and product data are not cardholder data. None identified for the assessed screens. No action required for the assessed screens. Verify that no cardholder data is stored anywhere in the application outside the assessed screens.
PC-004 Encrypt Transmission Req 4 ⚠️ All Shopify API calls are made server-side. No cardholder data is transmitted by the assessed screens. (Inferred from Shopify platform standards — verify against lib/shopify implementation and hosting configuration.) No explicit TLS configuration documentation. Whether HTTPS is enforced for all client-server communication is not documented. (Inferred from Shopify platform standards and Next.js/Vercel deployment pattern — verify against Vercel project settings, custom domain TLS configuration, and lib/shopify HTTP client.) Document and verify TLS 1.2+ enforcement for all connections.
PC-005 Anti-Malware Req 5 ❓ No anti-malware or endpoint protection documentation is present in the assessed screen specifications. Anti-malware controls for servers and development endpoints are not documented. (Organizational control — outside documentation scope.) Verify with infrastructure and IT teams that anti-malware controls are in place for all system components.
PC-006 Secure Development Req 6 ⚠️ The §17 Known Issues sections of the Search, Search Detail, and Product Detail screens document specific technical vulnerabilities (type-cast issue, unsafe featuredImage access, missing error boundaries). This demonstrates awareness of security issues in the development process. JSX auto-escaping is documented as preventing XSS. JSON-LD uses dangerouslySetInnerHTML with Shopify-sourced data (trusted source, low XSS risk). No documented secure development lifecycle (SDLC), code review process, security testing, or vulnerability management process. The documented known issues have not been remediated. Address documented known issues (type-cast, unsafe property access). Implement a formal SDLC with security code review. Conduct regular vulnerability scanning and penetration testing. (Organizational control — outside documentation scope for process elements.)
PC-007 Access Control Req 7 ⚠️ The assessed screens are intentionally public with no access control, which is appropriate for public product discovery. Shopify API credentials are server-only. No documentation of access controls for administrative functions, Shopify admin, or deployment infrastructure. Least-privilege access for administrative roles is not documented. [Not documented — WHO: Security lead and DevOps team; WHAT: What role-based access controls govern access to the Shopify admin, deployment pipeline, and server infrastructure? Are least-privilege principles applied?; WHERE: Insert in PC-007 Evidence column]
PC-008 Authentication Req 8 ❓ No authentication is implemented on the assessed screens (appropriate for public product discovery). Authentication mechanisms for administrative users and any authenticated customer flows are not documented. MFA for administrative access is not documented. [Not documented — WHO: Security lead; WHAT: What authentication mechanisms (MFA, unique IDs, password policies) are implemented for administrative access to the Shopify admin, deployment infrastructure, and any customer-facing authenticated flows?; WHERE: Insert in PC-008 Evidence column]
PC-009 Physical Security Req 9 N/A The application is hosted on Vercel (cloud platform) and uses Shopify's hosted infrastructure. Physical security of data centers is the responsibility of Vercel and Shopify, not the merchant. None for the merchant's direct responsibility. (Organizational control — outside documentation scope.) Verify Vercel's and Shopify's physical security certifications (SOC 2, ISO 27001) as part of vendor due diligence.
PC-010 Logging & Monitoring Req 10 ❌ All five assessed screen specifications explicitly state that no error tracking service calls or analytics event calls are present in the page components. No logging is documented at the page level. No application-level logging or monitoring is documented. Audit trails for access to system components are not documented. Implement application-level logging and error tracking. Implement server-side access logging. Verify whether Vercel provides access logs and whether they are retained for the required period (12 months, 3 months immediately available).
PC-011 Security Testing Req 11 ❓ No security testing documentation is present in the assessed screen specifications. The §17 Known Issues sections document known vulnerabilities, suggesting some level of security review has occurred. No documented vulnerability scanning, penetration testing, or intrusion detection. (Organizational control — outside documentation scope.) Establish a regular security testing program including vulnerability scanning and annual penetration testing.
PC-012 Security Policies Req 12 ❓ No security policy documentation is present in the assessed screen specifications. No documented information security policy, acceptable use policy, or incident response plan. (Organizational control — outside documentation scope.) Establish and maintain a comprehensive information security policy program.

8. WCAG 2.1 AA Compliance Checklist

8.1 Summary by Principle

Note: WCAG assessment is based on documented HTML structure and accessibility patterns in the five assessed screens. The Grid, ProductGridItems, ThreeItemGrid, Carousel, Gallery, ProductDescription, Footer, Prose, and GridTileImage components are referenced but not fully documented; their accessibility implementations cannot be fully assessed. A separate dedicated accessibility audit with assistive technology testing is recommended.

# Principle Criteria Count (AA) Compliant Partial Non-Compliant N/A Key Gaps
WC-001 1. Perceivable 13 3 4 2 4 Missing aria-live for dynamic search results; <time> element not used for dates; image alt text depends on undocumented components; carousel accessibility unknown
WC-002 2. Operable 10 2 3 1 4 No skip navigation documented; carousel keyboard controls unknown; no focus management for streaming SSR content; loading states absent
WC-003 3. Understandable 8 3 2 1 2 Server locale used for date formatting (not user locale); language attribute not documented; error identification absent for search no-results
WC-004 4. Robust 3 1 1 1 0 Suspense fallbacks lack ARIA loading indicators; dangerouslySetInnerHTML for JSON-LD is not accessibility-relevant but warrants review; assistive technology compatibility of undocumented components unknown

8.2 Perceivable — Detailed Findings

1.1.1 Non-text Content (AA) | Field | Detail | |---|---| | Status | ⚠️ Partially Compliant | | Evidence | Product Detail screen: GridTileImage receives alt={product.title} for related product images. Gallery images are passed with altText from Shopify's image metadata. Item Detail screen: images within Prose-rendered Shopify content may lack alt attributes if not authored correctly in Shopify admin. Home screen: ThreeItemGrid and Carousel image alt text is not documented. | | Gap | Alt text for images in ThreeItemGrid, Carousel, Gallery, and Prose-rendered content cannot be confirmed from the provided documentation. Shopify-authored content in Prose may contain images without alt text. | | Remediation | Audit all image-rendering components for alt text implementation. Implement a content governance process to ensure Shopify-authored page content includes alt text for all images. Verify Gallery component alt text implementation. |

1.3.1 Info and Relationships (AA) | Field | Detail | |---|---| | Status | ⚠️ Partially Compliant | | Evidence | Item Detail screen: <h1> for page title is semantically correct. Search screen: results summary uses <p> tag (appropriate). Product Detail screen: Related Products section uses <ul>/<li> list structure (appropriate). Search Detail screen: wraps content in <section> element (provides landmark). | | Gap | The Grid component's underlying HTML element is not documented — it may or may not use a semantic list structure. The Carousel component's structure is not documented. Heading hierarchy across the full page (including layout components) cannot be confirmed. | | Remediation | Document and verify the HTML output of Grid, ProductGridItems, ThreeItemGrid, and Carousel components. Ensure heading hierarchy is correct across all pages. |

1.3.2 Meaningful Sequence (AA) | Field | Detail | |---|---| | Status | ✅ Compliant | | Evidence | All assessed screens use server-side rendering with logical DOM order matching visual order. No CSS-only reordering patterns are documented. The two-column layout on Product Detail uses lg:flex-row which maintains logical source order. | | Gap | None identified from documentation. | | Remediation | None required. Verify with visual inspection that CSS grid/flex ordering does not reorder content in a way that breaks reading sequence. |

1.4.1 Use of Color (AA) | Field | Detail | |---|---| | Status | ❓ Cannot Assess | | Evidence | No color usage documentation is provided in the assessed screen specifications. Tailwind CSS classes are referenced but color values are not documented. | | Gap | Cannot determine whether color is used as the only visual means of conveying information. | | Remediation | [Not documented — WHO: Frontend development team; WHAT: Are there any UI elements that use color as the only means of conveying information (e.g., error states, active states, availability indicators)?; WHERE: Insert in WC-001 Key Gaps column] |

1.4.3 Contrast (Minimum) (AA) | Field | Detail | |---|---| | Status | ❓ Cannot Assess | | Evidence | No color or contrast documentation is provided. Tailwind CSS classes are referenced but specific color values are not documented. | | Gap | Cannot determine whether text meets 4.5:1 contrast ratio (normal text) or 3:1 (large text) requirements. | | Remediation | Conduct a color contrast audit using automated tools (axe, Lighthouse) and manual verification. Pay particular attention to the text-sm italic last-updated text on Item Detail and the results summary text on Search. |

1.4.4 Resize Text (AA) | Field | Detail | |---|---| | Status | ✅ Compliant | | Evidence | The application uses Tailwind CSS with responsive classes (text-5xl, text-sm, text-lg). Tailwind's default configuration uses rem-based font sizes, which respect browser font size settings. (Inferred from Tailwind CSS default configuration — verify against tailwind.config.js for any px-based overrides.) | | Gap | None identified from documentation, subject to verification of Tailwind configuration. | | Remediation | (Inferred from Tailwind CSS default configuration — verify against tailwind.config.js to confirm no px-based font size overrides that would prevent text resizing.) |

1.4.5 Images of Text (AA) | Field | Detail | |---|---| | Status | ✅ Compliant | | Evidence | All text content on the assessed screens is rendered as HTML text, not as images of text. Product titles, prices, and descriptions are rendered as text elements. | | Gap | Cannot confirm for images within Prose-rendered Shopify content or within ThreeItemGrid/Carousel components. | | Remediation | Verify that no images of text are used in undocumented components. Implement a content governance policy for Shopify-authored content. |

1.4.10 Reflow (AA) | Field | Detail | |---|---| | Status | ⚠️ Partially Compliant | | Evidence | The application uses responsive Tailwind CSS classes (grid-cols-1 sm:grid-cols-2 lg:grid-cols-3) that adapt layout to viewport width. The Product Detail screen uses overflow-x-auto for the related products list, which may require horizontal scrolling at narrow viewports. | | Gap | The overflow-x-auto on the Related Products section of the Product Detail screen may cause horizontal scrolling at 320px viewport width, which is a WCAG 1.4.10 failure for that section. The Carousel component may also require horizontal scrolling. | | Remediation | Test the Related Products section and Carousel at 320px viewport width. If horizontal scrolling is required for content that is not a map, table, or image, redesign to reflow vertically. |

1.4.11 Non-text Contrast (AA) | Field | Detail | |---|---| | Status | ❓ Cannot Assess | | Evidence | No documentation of UI component colors or border colors is provided. The Product Detail screen references a "light/dark mode border" on the main panel. | | Gap | Cannot determine whether UI components (buttons, form controls, focus indicators) meet the 3:1 contrast ratio requirement. | | Remediation | Conduct a non-text contrast audit for all interactive UI components, particularly in ProductDescription (variant selectors, add-to-cart button). |

1.4.12 Text Spacing (AA) | Field | Detail | |---|---| | Status | ❓ Cannot Assess | | Evidence | No CSS text spacing documentation is provided. | | Gap | Cannot determine whether the application supports text spacing overrides without loss of content or functionality. | | Remediation | Test the application with the WCAG text spacing bookmarklet to verify no content is lost when text spacing is overridden. |

1.4.13 Content on Hover or Focus (AA) | Field | Detail | |---|---| | Status | ❓ Cannot Assess | | Evidence | No hover or focus-triggered content is documented in the assessed screens. The GridTileImage component is described as rendering "a product image tile with label overlay" — whether this overlay appears on hover is not documented. | | Gap | Cannot determine whether any hover/focus-triggered content meets dismissibility, hoverable, and persistent requirements. | | Remediation | [Not documented — WHO: Frontend development team; WHAT: Does the GridTileImage label overlay or any other UI element appear on hover or focus? If so, does it meet WCAG 1.4.13 requirements (dismissible, hoverable, persistent)?; WHERE: Insert in WC-001 Key Gaps column] |

1.2.x Captions/Audio Description (AA) | Field | Detail | |---|---| | Status | N/A | | Evidence | No audio or video content is documented on any assessed screen. | | Gap | None identified. | | Remediation | Reassess if video or audio content is added to the application. |

8.3 Operable — Detailed Findings

2.1.1 Keyboard (AA) | Field | Detail | |---|---| | Status | ⚠️ Partially Compliant | | Evidence | The assessed screens use standard HTML elements (<a>, <p>, <h1>, <ul>, <li>) that are natively keyboard accessible. <Link> components render as <a> elements. The Search screen has no interactive elements in the page component itself. | | Gap | The Carousel component is documented as a "horizontally scrollable or animated carousel" — carousels are a commonly cited keyboard accessibility challenge. The Gallery component's image navigation controls are not documented. The ProductDescription component's variant selectors and add-to-cart button keyboard accessibility are not documented. | | Remediation | Conduct keyboard-only navigation testing of the Carousel, Gallery, and ProductDescription components. Ensure all interactive elements are reachable and operable via keyboard. |

2.1.2 No Keyboard Trap (AA) | Field | Detail | |---|---| | Status | ❓ Cannot Assess | | Evidence | No modal dialogs, custom dropdowns, or focus-trapping components are documented in the assessed screens. | | Gap | Cannot confirm for undocumented components (Gallery, ProductDescription, Carousel). | | Remediation | Test all interactive components for keyboard traps, particularly any modal or overlay components within ProductDescription. |

2.4.1 Bypass Blocks (AA) | Field | Detail | |---|---| | Status | ❌ Non-Compliant | | Evidence | No skip navigation links are documented in any assessed screen. The Home screen explicitly states that no wrapping landmark element is introduced at the page level, and that semantic structure is the responsibility of child components and the root layout. | | Gap | No skip navigation link is documented. Whether the root layout.tsx provides a skip link is not documented. | | Remediation | Implement a "Skip to main content" link in the root layout. Ensure a <main> landmark wraps the primary content of each page. [Not documented — WHO: Frontend development team; WHAT: Does the root layout.tsx include a skip navigation link and a <main> landmark element?; WHERE: Insert in WC-002 Key Gaps column] |

2.4.2 Page Titled (AA) | Field | Detail | |---|---| | Status | ✅ Compliant | | Evidence | The Home screen exports static metadata with a title. The Item Detail screen uses generateMetadata to set page title from page.seo?.title or page.title. The Product Detail screen uses generateMetadata to set page title from product.seo?.title or product.title. The Search Detail screen uses generateMetadata to set page title from collection SEO fields. | | Gap | The Search screen (/search) does not document a generateMetadata export or static metadata. Whether the search results page has a descriptive title is not confirmed. | | Remediation | Verify that the Search screen (/search) has a descriptive page title. Add generateMetadata or static metadata to the Search screen if not present. |

2.4.3 Focus Order (AA) | Field | Detail | |---|---| | Status | ⚠️ Partially Compliant | | Evidence | Server-side rendered pages with logical DOM order should have a natural focus order. The Product Detail screen's two-column layout (Gallery left, ProductDescription right on large screens) maintains source order. | | Gap | The Carousel component's focus order is not documented. The Gallery component's focus order for image navigation is not documented. Streaming SSR via <Suspense> may cause focus order issues if content streams in after initial render. | | Remediation | Test focus order across all pages, particularly for the Carousel and Gallery components. Verify that streaming SSR does not disrupt focus order. |

2.4.4 Link Purpose (AA) | Field | Detail | |---|---| | Status | ⚠️ Partially Compliant | | Evidence | Product Detail screen: Related product links wrap GridTileImage with alt={product.title}, providing a discernible link name. Item Detail screen: links within Prose-rendered Shopify content are not controlled by this screen's code. | | Gap | Whether related product links have a discernible accessible name depends on how GridTileImage renders its underlying <img> and whether the link has visible text. Links within Shopify-authored content in Prose may have non-descriptive text (e.g., "click here"). | | Remediation | Verify that GridTileImage provides a discernible accessible name for its wrapping link. Implement a content governance policy for Shopify-authored content to ensure descriptive link text. |

2.4.5 Multiple Ways (AA) | Field | Detail | |---|---| | Status | ✅ Compliant | | Evidence | The application provides multiple ways to find content: the Search screen (/search) provides search functionality, the Search Detail screen (/search/[collection]) provides collection browsing, and the Home screen provides featured product discovery. The Footer likely provides site navigation. | | Gap | Cannot fully confirm without documentation of the Footer and header/navbar components. | | Remediation | Verify that the Footer and header/navbar provide site-wide navigation as a second way to find content. |

2.4.6 Headings and Labels (AA) | Field | Detail | |---|---| | Status | ⚠️ Partially Compliant | | Evidence | Item Detail screen: <h1> for page title is descriptive. Product Detail screen: <h2> for "Related Products" section is appropriate. Search screen: no headings are documented in the page component. | | Gap | The Search screen has no documented heading structure. The heading hierarchy across the full page (including layout components and ProductDescription) cannot be confirmed. | | Remediation | Add a descriptive heading to the Search screen (e.g., "Search Results" or "Showing results for [query]"). Verify heading hierarchy across all pages. |

2.4.7 Focus Visible (AA) | Field | Detail | |---|---| | Status | ❓ Cannot Assess | | Evidence | No focus indicator styling is documented in the assessed screen specifications. | | Gap | Cannot determine whether interactive elements have visible focus indicators. | | Remediation | Verify that all interactive elements have visible focus indicators meeting WCAG 2.4.7 requirements. Tailwind CSS's default focus styles may need to be verified or enhanced. |

2.5.x Pointer Gestures/Input (AA) | Field | Detail | |---|---| | Status | ❓ Cannot Assess | | Evidence | The Carousel component is described as supporting "scroll/swipe gestures." No documentation of pointer gesture requirements. | | Gap | Cannot determine whether the Carousel requires multipoint or path-based gestures without a single-pointer alternative. | | Remediation | Verify that the Carousel provides single-pointer alternatives (previous/next buttons) for all swipe gestures. |

8.4 Understandable — Detailed Findings

3.1.1 Language of Page (AA) | Field | Detail | |---|---| | Status | ❓ Cannot Assess | | Evidence | No lang attribute documentation is present in the assessed screen specifications. The root layout.tsx would typically set the lang attribute on the <html> element. | | Gap | Cannot confirm that the <html lang="..."> attribute is set correctly. | | Remediation | [Not documented — WHO: Frontend development team; WHAT: Does the root layout.tsx set the lang attribute on the <html> element with the correct language code?; WHERE: Insert in WC-003 Key Gaps column] |

3.1.2 Language of Parts (AA) | Field | Detail | |---|---| | Status | ❓ Cannot Assess | | Evidence | No multi-language content is documented. Shopify-authored content in Prose may contain content in languages other than the page language. | | Gap | Cannot determine whether language changes within content are marked with lang attributes. | | Remediation | Implement a content governance policy for Shopify-authored content to ensure language changes are marked appropriately. |

3.2.1 On Focus (AA) | Field | Detail | |---|---| | Status | ✅ Compliant | | Evidence | No context changes on focus are documented in the assessed screens. The assessed screens use standard navigation patterns (URL changes on sort/search submission). | | Gap | Cannot confirm for undocumented interactive components (Carousel, Gallery, ProductDescription). | | Remediation | Verify that no context changes occur on focus in undocumented components. |

3.2.2 On Input (AA) | Field | Detail | |---|---| | Status | ✅ Compliant | | Evidence | Sort and search parameter changes navigate to a new URL (full page reload), which is a predictable context change. No automatic context changes on input are documented. | | Gap | Cannot confirm for undocumented interactive components. | | Remediation | Verify that variant selection in ProductDescription does not cause unexpected context changes. |

3.2.3 Consistent Navigation (AA) | Field | Detail | |---|---| | Status | ⚠️ Partially Compliant | | Evidence | The Footer component is rendered consistently on the Home and Product Detail screens. The header/navbar (containing the search input and sort controls) is expected to be in a shared layout component. | | Gap | Whether navigation is consistent across all pages cannot be confirmed without documentation of the root layout.tsx and header/navbar components. | | Remediation | Verify that navigation components (header, footer, breadcrumbs) appear in the same relative order on all pages. |

3.3.1 Error Identification (AA) | Field | Detail | |---|---| | Status | ❌ Non-Compliant | | Evidence | The Search screen displays a "no products match" message when a search returns no results, but this is not an error identification mechanism in the WCAG sense. No form validation errors are documented on the assessed screens (no forms are present). The sort parameter fallback silently applies defaultSort without informing the user. | | Gap | The Search screen's "no results" state does not use role="alert" or aria-live to announce the state change to screen reader users. No error identification is documented for any edge case. | | Remediation | Add role="status" or aria-live="polite" to the search results summary on the Search screen. Ensure the "no results" state is announced to screen reader users. |

3.3.2 Labels or Instructions (AA) | Field | Detail | |---|---| | Status | ❓ Cannot Assess | | Evidence | No form inputs are present on the assessed screens. The search input and sort controls are in undocumented parent layout components. | | Gap | Cannot assess label implementation for the search input and sort controls. | | Remediation | [Not documented — WHO: Frontend development team; WHAT: Do the search input field and sort dropdown in the header/navbar have visible labels or aria-label attributes?; WHERE: Insert in WC-003 Key Gaps column] |

3.3.3 Error Suggestion (AA) | Field | Detail | |---|---| | Status | N/A | | Evidence | No forms with validation errors are present on the assessed screens. | | Gap | None for the assessed screens. | | Remediation | Assess checkout and account management screens separately. |

3.3.4 Error Prevention (AA) | Field | Detail | |---|---| | Status | N/A | | Evidence | No forms with legal, financial, or data-deletion consequences are present on the assessed screens. | | Gap | None for the assessed screens. | | Remediation | Assess checkout and account management screens separately. |

8.5 Robust — Detailed Findings

4.1.1 Parsing (AA) | Field | Detail | |---|---| | Status | ✅ Compliant | | Evidence | The application uses React/Next.js, which generates well-formed HTML. JSX enforces proper element nesting. The Prose component renders Shopify-authored HTML, which may contain parsing errors if the content is malformed. | | Gap | Shopify-authored HTML content rendered via Prose may contain malformed HTML if not properly validated in Shopify's admin. | | Remediation | Validate HTML output using automated tools (W3C Validator, axe). Implement content governance for Shopify-authored content. |

4.1.2 Name, Role, Value (AA) | Field | Detail | |---|---| | Status | ⚠️ Partially Compliant | | Evidence | Standard HTML elements (<h1>, <p>, <ul>, <li>, <a>, <section>) provide implicit ARIA roles. No explicit ARIA attributes are documented in the assessed screen page components. The Search screen documents the absence of role="status" or aria-atomic on the results summary. The Item Detail screen documents the absence of ARIA attributes. | | Gap | The Carousel component requires ARIA roles and properties for accessibility (e.g., role="region", aria-label, aria-live for auto-advancing carousels). The Gallery component requires ARIA for image navigation controls. The ProductDescription component requires ARIA for variant selectors and add-to-cart. These are not documented. | | Remediation | Audit all interactive components (Carousel, Gallery, ProductDescription) for ARIA implementation. Add role="status" to the Search screen results summary. Add <time datetime="..."> to the Item Detail last-updated date. |

4.1.3 Status Messages (AA) | Field | Detail | |---|---| | Status | ❌ Non-Compliant | | Evidence | The Search screen documents the absence of aria-live region for result count changes. The Search screen documents the absence of role="status" on the results summary. The Search Detail screen documents the absence of aria-live for the empty state message. | | Gap | Status messages (search results count, "no products found", "no products in collection") are not programmatically determinable without focus. Screen reader users will not receive these announcements unless they navigate to the element. | | Remediation | Add role="status" and aria-live="polite" to the results summary on the Search screen. Add aria-live="polite" to the empty state message on the Search Detail screen. Ensure status messages are announced without requiring focus. |

9. Cross-Framework Gap Analysis

Gap Area GDPR CCPA/CPRA SOC 2 PCI-DSS WCAG Impact Priority
Privacy Notice / Disclosure Art. 13–14 §1798.100(b) P1.1 — — High — Direct regulatory exposure for public-facing storefront. Absence of a privacy notice is a clear violation of both GDPR and CCPA/CPRA. High
Consent & Legal Basis Art. 6–7 §1798.120 (opt-out) P1.1 — — High — No documented legal basis for any data processing. No opt-out mechanism for sale/sharing of personal information. High
Logging & Monitoring Art. 33 (breach detection) §1798.150 (reasonable security) CC7.1, CC7.2 Req 10 — High — Without logging, breach detection and incident response are impossible. Affects four frameworks simultaneously. High
Data Subject Rights Mechanisms Art. 15–21 §1798.100, §1798.105, §1798.106, §1798.120 P1.1 — — High — No DSAR, deletion, correction, or opt-out mechanisms documented. Core consumer rights are unaddressed. High
Security of Processing / Reasonable Security Art. 32 §1798.150 CC6.1, CC6.2 Req 4, Req 6 — High — No TLS documentation, no WAF, no security testing documented. Affects four frameworks. High
Access Control (Administrative) Art. 5(1)(f) — CC5.1, CC5.2 Req 7, Req 8 — Medium — Administrative access controls for Shopify admin and deployment infrastructure are not documented. Medium
Error Handling & Resilience Art. 32 (integrity) §1798.150 A1.1, SC-012 Req 6 4.1.3 (status messages) Medium — Missing error boundaries, unsafe property access, and type-cast issues affect security, availability, and accessibility simultaneously. Medium
Skip Navigation / Landmark Structure — — — — 2.4.1, 4.1.2 Medium — Absence of skip navigation and confirmed landmark structure affects all pages. Medium
Status Message Announcements — — — — 3.3.1, 4.1.3 Medium — Search results and empty states are not announced to screen reader users. Affects Search and Search Detail screens. Medium
Data Retention / Storage Limitation Art. 5(1)(e) §1798.100(c) C1.2, SC-014 Req 3 — Medium — No retention policy documented for cache, logs, or any data stored by the application. Medium
Vendor / Service Provider Agreements Art. 28 (DPA with Shopify) §1798.140(ag) CC9.2 Req 12 — Medium — No documented DPA with Shopify or other service providers. Medium
searchParams Type-Cast Vulnerability Art. 32 §1798.150 SC-012, CC6.1 Req 6 — Low — Minor robustness gap documented in §17 of Search and Search Detail screens. Low direct security risk but represents a data quality and integrity gap. Low
Date Formatting (Server Locale) — — — — 3.1.1 (language) Low — Server locale used for date formatting on Item Detail screen may produce unexpected formats for international users. Low
<time> Element for Dates — — — — 4.1.2 Low — Item Detail last-updated date uses <p> instead of <time datetime="...">. Low

10. Remediation Roadmap

Phase 1: Immediate (0–30 days) — Non-Compliant Items with High Regulatory Risk

Phase 2: Short-Term (1–3 months) — Partially Compliant Items Needing Completion

Phase 3: Medium-Term (3–6 months) — Enhancement Items and Best Practices

Phase 4: Ongoing — Continuous Compliance Monitoring and Improvement

11. Glossary

Regulatory Acronyms

Term Definition
GDPR General Data Protection Regulation — EU Regulation 2016/679, governing the processing of personal data of individuals in the European Economic Area.
CCPA California Consumer Privacy Act — California Civil Code §1798.100 et seq., granting California residents rights over their personal information.
CPRA California Privacy Rights Act — Amendment to CCPA (effective January 1, 2023) that added new rights (right to correct, right to limit sensitive PI) and created the California Privacy Protection Agency.
SOC 2 System and Organization Controls 2 — An auditing standard developed by the AICPA assessing service organizations' controls relevant to security, availability, processing integrity, confidentiality, and privacy.
PCI-DSS Payment Card Industry Data Security Standard — A set of security standards designed to ensure that all companies that accept, process, store, or transmit credit card information maintain a secure environment.
WCAG Web Content Accessibility Guidelines — Guidelines published by the W3C's Web Accessibility Initiative (WAI) defining how to make web content more accessible to people with disabilities.
DPA Data Processing Agreement — A contract between a data controller and a data processor required under GDPR Art. 28, governing how the processor handles personal data on behalf of the controller. Also: Data Protection Authority — the national regulatory body responsible for enforcing GDPR in each EU member state.
DPIA Data Protection Impact Assessment — A process required under GDPR Art. 35 for processing activities likely to result in high risk to individuals' rights and freedoms.
DPO Data Protection Officer — A role required under GDPR Art. 37 for certain organizations, responsible for overseeing data protection strategy and compliance.
RoPA Records of Processing Activities — Documentation required under GDPR Art. 30 describing all personal data processing activities conducted by an organization.
DSAR Data Subject Access Request — A request made by an individual exercising their rights under GDPR (Art. 15–22) or CCPA to access, delete, correct, or obtain their personal data.
SAQ A Self-Assessment Questionnaire A — The simplest PCI-DSS self-assessment form, applicable to merchants who have fully outsourced all cardholder data functions to PCI-compliant third parties (such as Shopify-hosted checkout).
QSA Qualified Security Assessor — A company certified by the PCI Security Standards Council to conduct PCI-DSS assessments.
WAF Web Application Firewall — A security control that monitors and filters HTTP traffic between a web application and the internet.
MFA Multi-Factor Authentication — An authentication method requiring two or more verification factors.
TLS Transport Layer Security — A cryptographic protocol providing secure communication over a network. Successor to SSL.
SLA Service Level Agreement — A commitment between a service provider and a client defining the expected level of service, including uptime.
RTO Recovery Time Objective — The maximum acceptable time to restore a system after a disruption.
RPO Recovery Point Objective — The maximum acceptable amount of data loss measured in time.
ISR Incremental Static Regeneration — A Next.js feature allowing statically generated pages to be revalidated and updated in the background at a configured interval.

GDPR Articles Referenced

Article Name
Art. 5 Principles relating to processing of personal data
Art. 6 Lawfulness of processing
Art. 7 Conditions for consent
Art. 12 Transparent information, communication and modalities for the exercise of the rights of the data subject
Art. 13 Information to be provided where personal data are collected from the data subject
Art. 14 Information to be provided where personal data have not been obtained from the data subject
Art. 15 Right of access by the data subject
Art. 16 Right to rectification
Art. 17 Right to erasure ('right to be forgotten')
Art. 18 Right to restriction of processing
Art. 20 Right to data portability
Art. 21 Right to object
Art. 22 Automated individual decision-making, including profiling
Art. 25 Data protection by design and by default
Art. 28 Processor
Art. 30 Records of processing activities
Art. 32 Security of processing
Art. 33 Notification of a personal data breach to the supervisory authority
Art. 34 Communication of a personal data breach to the data subject
Art. 35 Data protection impact assessment
Art. 37 Designation of the data protection officer

CCPA/CPRA Sections Referenced

Section Name
§1798.100 Right to know about personal information collected, disclosed, or sold
§1798.100(b) Privacy notice requirement
§1798.100(c) Data minimization (CPRA)
§1798.105 Right to delete personal information
§1798.106 Right to correct inaccurate personal information (CPRA)
§1798.120 Right to opt-out of sale or sharing of personal information
§1798.121 Right to limit use and disclosure of sensitive personal information (CPRA)
§1798.125 Right to non-discrimination
§1798.140(ae) Definition of sensitive personal information (CPRA)
§1798.140(ag) Definition of service provider
§1798.150 Private right of action for data breaches; reasonable security requirement

SOC 2 Trust Services Criteria Referenced

Criterion Name
CC1.1 Control Environment — Board oversight of security and compliance
CC5.1 Logical and Physical Access Controls — Logical access security
CC5.2 Logical and Physical Access Controls — Authentication
CC6.1 Logical and Physical Access Controls — Encryption
CC6.2 Logical and Physical Access Controls — Transmission security
CC6.3 Logical and Physical Access Controls — Change management
CC7.1 System Operations — Monitoring
CC7.2 System Operations — Incident response
CC8.1 Change Management — Risk assessment
CC9.2 Risk Mitigation — Vendor and business partner management
A1.1 Availability — Processing integrity and availability commitments
A1.2 Availability — Recovery
PI1.1 Processing Integrity — Data quality
C1.1 Confidentiality — Data classification
C1.2 Confidentiality — Data disposal
P1.1 Privacy — Privacy notice

PCI-DSS v4.0 Requirements Referenced

Requirement Name
Req 1 Install and maintain network security controls
Req 2 Apply secure configurations to all system components
Req 3 Protect stored account data
Req 4 Protect cardholder data with strong cryptography during transmission over open, public networks
Req 5 Protect all systems and networks from malicious software
Req 6 Develop and maintain secure systems and software
Req 7 Restrict access to system components and cardholder data by business need to know
Req 8 Identify users and authenticate access to system components
Req 9 Restrict physical access to cardholder data
Req 10 Log and monitor all access to system components and cardholder data
Req 11 Test security of systems and networks regularly
Req 12 Support information security with organizational policies and programs

WCAG 2.1 AA Success Criteria Referenced

Criterion Name Level
1.1.1 Non-text Content A
1.2.x Time-based Media (Captions, Audio Description) A/AA
1.3.1 Info and Relationships A
1.3.2 Meaningful Sequence A
1.4.1 Use of Color A
1.4.3 Contrast (Minimum) AA
1.4.4 Resize Text AA
1.4.5 Images of Text AA
1.4.10 Reflow AA
1.4.11 Non-text Contrast AA
1.4.12 Text Spacing AA
1.4.13 Content on Hover or Focus AA
2.1.1 Keyboard A
2.1.2 No Keyboard Trap A
2.4.1 Bypass Blocks A
2.4.2 Page Titled A
2.4.3 Focus Order A
2.4.4 Link Purpose (In Context) A
2.4.5 Multiple Ways AA
2.4.6 Headings and Labels AA
2.4.7 Focus Visible AA
2.5.x Pointer Gestures / Input Modalities A/AA
3.1.1 Language of Page A
3.1.2 Language of Parts AA
3.2.1 On Focus A
3.2.2 On Input A
3.2.3 Consistent Navigation AA
3.3.1 Error Identification A
3.3.2 Labels or Instructions A
3.3.3 Error Suggestion AA
3.3.4 Error Prevention (Legal, Financial, Data) AA
4.1.1 Parsing A
4.1.2 Name, Role, Value A
4.1.3 Status Messages AA

Application and Technology Terms

Term Definition
React Server Component (RSC) A Next.js App Router component that renders exclusively on the server, sends no client-side JavaScript, and cannot use React hooks. All assessed page components are RSCs.
Next.js App Router The Next.js 13+ routing system based on the app/ directory, supporting Server Components, layouts, streaming SSR, and file-based metadata exports.
Shopify Storefront API Shopify's public-facing GraphQL API used to query product, collection, page, and cart data for storefronts. Distinct from the Admin API. Accessed via a Storefront Access Token.
generateMetadata A Next.js App Router convention — an exported async function from a page.tsx file that returns SEO metadata (<title>, <meta>, OpenGraph tags) for the route.
notFound() A Next.js utility function that, when called, halts rendering and triggers the nearest not-found.tsx boundary or the default 404 page.
Streaming SSR A Next.js feature using React <Suspense> boundaries to send the HTML shell to the browser immediately and stream in suspended component content as server-side rendering completes.
dangerouslySetInnerHTML A React prop that bypasses React's HTML escaping to inject raw HTML strings into the DOM. Used in the Product Detail screen for JSON-LD structured data.
JSON-LD JavaScript Object Notation for Linked Data — a method of encoding structured data in a <script type="application/ld+json"> tag for search engine rich results.
Schema.org A collaborative vocabulary for structured data markup, used in the Product Detail screen's JSON-LD to describe products for search engines.
OpenGraph A metadata protocol controlling how a URL is represented when shared on social media platforms, implemented via <meta> tags in the page <head>.
HIDDEN_PRODUCT_TAG A Shopify product tag constant that marks a product as non-indexable by search engines. Products with this tag are accessible by URL but excluded from SEO indexing.
Vercel The cloud deployment platform optimized for Next.js applications, providing CDN, edge functions, and build infrastructure for this storefront.
lib/shopify An internal service module that abstracts all Shopify Storefront API calls, including authentication, GraphQL query construction, error handling, and caching configuration. Not fully documented in the assessed screens.
Prose An internal component that applies typographic styling to raw HTML content from Shopify, used on the Item Detail screen.
SHOPIFY_STOREFRONT_ACCESS_TOKEN A server-only environment variable containing the authentication token for the Shopify Storefront API. Never exposed to the client bundle.
SHOPIFY_STORE_DOMAIN A server-only environment variable containing the Shopify store hostname. Never exposed to the client bundle.

End of Regulatory Compliance Checklist Generated by DocAgent — automated codebase documentation analysis. Subject matter expert review is recommended before distribution. Document Date: April 2026 | Application: commerce | Screens Assessed: 5