Risk Register + Engineering Controls Risk Register

Technical Annex to the Quality Policy Statement

Document	Risk Register + Engineering Controls
Status	APPROVED — Ready for publication at https://elogic.co/risk-register/
Version	v3.0 — February 27, 2026
Review Cadence	Annual
Document Owner (DRI)	Paul Okhrem, Co-Founder & CEO
Signing Authority	Paul Okhrem, Co-Founder & CEO \| Igor Iakovliev, Co-Founder
Parent Document	https://elogic.co/quality-policy-statement/
Security Contact	security@elogic.co
Compliance Contact	legal@elogic.co

Evidence Tier:

✓ CONFIRMED — specific tooling, threshold, or practice in operation, evidenced against a named public standard or verifiable industry benchmark

Tier-1 Project Definition:

Controls marked as applying to ‘Tier-1 projects’ apply to any engagement meeting one or more of the following criteria: (1) PCI DSS scope — payment data flows through Elogic-managed code; (2) Regulated industry — healthcare, financial services, or government; (3) Complex integration — ≥5 third-party system integrations; (4) Enterprise SLA tier — contracted P1 response SLA; (5) Annual GMV threshold — client platform processes >€10M annual GMV. All other engagements receive the universal baseline controls stated in this document. The engagement SOW defines the applicable tier.

1. Acronym Glossary

This document is intended for both technical and non-technical readers, including procurement officers, legal teams, and executive stakeholders. All acronyms used in this document are defined below and expanded on first substantive use within each section.

Acronym	Full Form	Definition
A11y	Accessibility	Shorthand for ‘accessibility’ (11 letters between ‘a’ and ‘y’).
AICPA	American Institute of CPAs	The professional body that owns the SOC 2 audit framework.
APM	Application Performance Monitoring	Real-time tracking of software performance in production (e.g. New Relic APM).
BFCM	Black Friday / Cyber Monday	The peak retail trading period, typically the last week of November.
BCP	Business Continuity Plan	A documented plan for maintaining operations during and after a major incident.
BC/DR	Business Continuity / Disaster Recovery	Combined term for the plans and controls that keep a business running and restore systems after a failure.
CDN	Content Delivery Network	A distributed network of servers that delivers web content from locations close to the end user, reducing load time.
CI/CD	Continuous Integration / Continuous Delivery	Automated processes for building, testing, and deploying software changes frequently and reliably.
CLS	Cumulative Layout Shift	A Google Core Web Vital measuring visual stability — how much page content moves unexpectedly during load. Target: ≤0.1.
CPD	Continuing Professional Development	Ongoing learning activities that maintain and extend professional skills and certifications.
CVE	Common Vulnerabilities and Exposures	A public catalogue of known security vulnerabilities, each assigned a unique identifier (e.g. CVE-2024-12345).
CVSS	Common Vulnerability Scoring System	An industry-standard 0–10 scale for rating the severity of security vulnerabilities. Critical ≥9.0, High 7.0–8.9, Medium 4.0–6.9, Low <4.0.
CWV	Core Web Vitals	Google’s set of real-user performance metrics (LCP, CLS, INP) that directly influence search ranking.
DAST	Dynamic Application Security Testing	Security testing performed on a running application, simulating how an attacker would probe it from outside.
DFD	Data Flow Diagram	A diagram showing how data moves between system components, used in threat modeling to identify trust boundaries and attack surfaces.
DoD	Definition of Done	A formal checklist that must be satisfied before a piece of work is considered complete and releasable.
DORA	DevOps Research and Assessment	An annual research programme (now part of Google Cloud) that benchmarks software delivery performance. Key metrics: deployment frequency, change failure rate, lead time, and recovery time.
DR	Disaster Recovery	The set of processes for restoring systems and data after a major failure or outage.
EAA	EU Accessibility Act	EU Directive 2019/882, enforceable from June 28 2025, requiring digital products and services sold in the EU to meet WCAG 2.1 AA accessibility standards.
ERP	Enterprise Resource Planning	Business software that integrates core processes such as finance, inventory, and order management (e.g. SAP, Microsoft Dynamics).
GDPR	General Data Protection Regulation	EU Regulation 2016/679 governing the collection, processing, and storage of personal data for EU residents.
GMV	Gross Merchandise Value	The total value of goods sold through an ecommerce platform over a given period.
INP	Interaction to Next Paint	A Google Core Web Vital measuring responsiveness — the time from user interaction to the next visual update. Target: ≤200ms. Replaced FID as a Core Web Vital in March 2024.
ISMS	Information Security Management System	The overarching framework of policies, processes, and controls an organisation uses to manage information security, as defined by ISO 27001.
ISTQB	International Software Testing Qualifications Board	The global body that defines and certifies software testing qualifications (Foundation, Advanced, Expert levels).
JML	Joiners / Movers / Leavers	The process for managing user access across the employee lifecycle — provisioning on joining, updating on role change, and revoking on departure.
LCP	Largest Contentful Paint	A Google Core Web Vital measuring perceived load speed — the time until the largest visible content element is rendered. Target: ≤2.5 seconds.
MFA	Multi-Factor Authentication	A security control requiring two or more verification factors (e.g. password + authenticator app) to access a system.
MSA	Managed Services Agreement	A contract under which Elogic provides ongoing operational support and monitoring after an initial project delivery.
NDA	Non-Disclosure Agreement	A legal contract restricting the sharing of confidential information with third parties.
NIST	National Institute of Standards and Technology	A US federal agency that publishes widely adopted cybersecurity frameworks, including the SSDF and SP 800 series.
NPS	Net Promoter Score	A customer satisfaction metric on a 0–10 scale. Scores of 70+ are considered world-class.
OWASP	Open Worldwide Application Security Project	A non-profit foundation that publishes the OWASP Top 10 (most critical web application security risks), SAMM, and other security guidance used globally.
PAM	Privileged Access Management	Controls governing access to high-privilege accounts and systems, including time-limited sessions and full audit logging.
PCI DSS	Payment Card Industry Data Security Standard	A global security standard (v4.0 as of 2024) governing organisations that handle cardholder data. Requirement 6 covers secure development; Requirement 11 covers security testing.
PDP	Product Detail Page	The ecommerce page that displays information about a specific product.
PII	Personally Identifiable Information	Any data that can be used to identify an individual — names, email addresses, payment details, IP addresses, etc. Governed by GDPR and equivalent regulations.
PLP	Product Listing Page	The ecommerce page displaying a category or search results grid of products.
PMI / PMBOK	Project Management Institute / Project Management Body of Knowledge	PMI is the global professional body for project managers. PMBOK (7th edition) is its framework for project management best practices. PMP® is PMI’s practitioner certification.
PR	Pull Request	A code review mechanism in version control (e.g. GitHub) where changes are reviewed and approved before merging into the main branch.
PTaaS	Penetration Testing as a Service	A subscription model for penetration testing that provides on-demand access to vetted security researchers (e.g. Cobalt, BreachLock).
QBR	Quarterly Business Review	A regular structured meeting between Elogic and the client to review performance KPIs, defect metrics, and roadmap priorities.
RBAC	Role-Based Access Control	An access control model where permissions are assigned to roles rather than individuals, enforcing least-privilege access.
RFC 9116	Request for Comments 9116	An internet standard (published April 2022) defining the security.txt file format for coordinated vulnerability disclosure.
RPO	Recovery Point Objective	The maximum acceptable amount of data loss measured in time — how far back in time a restore can go after a failure.
RTO	Recovery Time Objective	The maximum acceptable time to restore a system or service after a failure.
RUM	Real User Monitoring	Performance data collected from actual users’ browsers in production (as opposed to synthetic lab tests). Elogic uses New Relic Browser for RUM.
SAMM	Software Assurance Maturity Model	The OWASP framework for evaluating and improving a software security programme across governance, design, implementation, verification, and operations.
SAST	Static Application Security Testing	Automated security analysis of source code without executing it, identifying vulnerabilities at development time.
SBOM	Software Bill of Materials	A machine-readable inventory of all components, libraries, and dependencies in a software product. Required by PCI DSS v4.0 Req 6.3.2.
SCA	Software Composition Analysis	Automated scanning of third-party dependencies and open-source components for known vulnerabilities and licence compliance issues.
SDLC	Software Development Life Cycle	The end-to-end process of planning, building, testing, and deploying software.
SLA	Service Level Agreement	A contractual commitment defining the minimum acceptable performance standard (e.g. P1 incident response within 15 minutes).
SOC 2	System and Organisation Controls 2	An auditing standard developed by the AICPA that evaluates a service provider’s controls across five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy.
SOW	Statement of Work	A contract document defining the scope, deliverables, and acceptance criteria for a specific engagement.
SSDF	Secure Software Development Framework	NIST SP 800-218 — a framework of practices for integrating security throughout the software development lifecycle.
STRIDE	Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege	A threat modeling methodology developed at Microsoft that classifies threats against six security properties.
TTFB	Time to First Byte	A web performance metric measuring the time from the browser’s request to receiving the first byte of a response from the server. Target: ≤800ms.
TSC	Trust Services Criteria	The AICPA’s control categories evaluated in a SOC 2 audit: Security (CC), Availability (A), Processing Integrity (PI), Confidentiality (C), and Privacy (P).
UAT	User Acceptance Testing	A testing phase in which the client or end users validate that the delivered software meets agreed requirements before go-live.
VDP	Vulnerability Disclosure Policy	A published policy defining how external security researchers should report vulnerabilities and how Elogic will respond.
WAF	Web Application Firewall	A security layer that filters and monitors HTTP traffic to and from a web application, blocking common attack patterns.
WCAG	Web Content Accessibility Guidelines	The W3C international standard for digital accessibility. WCAG 2.1 Level AA is the threshold required by the EU Accessibility Act.

2. Executive Summary

The Safe Choice for Complex Commerce is not a slogan — it is an operational commitment backed by named controls, specific tooling, and verifiable standards. Elogic Commerce has delivered 500+ ecommerce projects across 17 years, serving global enterprises across manufacturing, telecom, consumer goods, fashion, and healthcare — including Fortune 500 organisations. Reference clients and case studies are available on request. Founded in 2009 and headquartered in Tallinn, Estonia (with offices in New York, London, Dresden, Stockholm, and Prague), Elogic holds ISO 27001, ISO 9001, and SOC 2 Type II certifications and is recognised as Clutch Premier Verified Agency (2025), ranked #1 Global Leader in Adobe Commerce Development (Clutch, February 2026), and listed in the FT 1000 Europe’s Fastest Growing Companies. Delivery is supported by a verified NPS of 70 on Clutch and governed by PMI-aligned project management (PMP®-certified Project Managers) and ISTQB-certified QA professionals embedded from sprint zero through hypercare.

This document maps Elogic’s engineering controls across four domains — Secure SDLC (Software Development Life Cycle), QA (Quality Assurance) Automation, Performance Budgets, and Release Management — to the control requirements of ISO 9001:2015, ISO/IEC 27001:2022, SOC 2 (System and Organisation Controls 2, AICPA TSC 2017), NIST SSDF SP 800-218 (Secure Software Development Framework), PCI DSS v4.0 (Payment Card Industry Data Security Standard), DORA 2024 (DevOps Research and Assessment), and Google Core Web Vitals (CWV). Every claim in this document is ✓ CONFIRMED: supported by a named public standard, a verifiable industry benchmark, or a specific tool in operation. No aspirational or suggested controls are included.

This is version 3.0, signed by Paul Okhrem (Co-Founder & CEO) and Igor Iakovliev (Co-Founder) and approved for external publication at elogic.co/risk-register. It is the technical annex to the Quality Policy Statement (https://elogic.co/quality-policy-statement/). Clients may request evidence of specific controls for vendor due diligence via security@elogic.co or legal@elogic.co.

Elogic Commerce holds ISO 27001 (Information Security Management), ISO 9001 (Quality Management), and SOC 2 Type II certifications. This document provides the technical control evidence underpinning those certifications and is the annex referenced in client due diligence and procurement questionnaires.

3. Risk Register

16 risks across 4 domains. Inherent ratings reflect exposure before controls. Residual ratings reflect remaining exposure with all stated controls operational. All controls are ✓ CONFIRMED.

L / S: H = High | M = Medium | L = Low

ID	Domain	Risk Statement	L	S	Justification	Owner	Controls (all ✓ CONFIRMED)	Residual
SD-01	Secure SDLC	Vulnerable third-party dependency via module update → data breach, PCI DSS violation	H	H	Large dependency footprints with high historical CVE rates across Magento/Shopify ecosystems.	Lead Engineer	✓ Snyk SCA (Software Composition Analysis) on every PR + nightly (CVSS ≥7.0 = build fail). SBOM generated per PCI DSS v4.0 Req 6.3.2. Remediation SLAs: Critical ≤48h, High ≤7d.	M
SD-02	Secure SDLC	Injection vulnerability reaching production → PII exfiltration, regulatory fine	H	H	Ecommerce handles PII and payment data; injection is persistent OWASP Top 10 A03 risk.	Lead Engineer	✓ ≥2 reviewer PR gate + CODEOWNERS. ✓ GitGuardian secrets detection. ✓ STRIDE (threat modeling methodology) for Tier-1 projects. ✓ Annual pentest (OWASP Top 10 scope).	M
SD-03	Secure SDLC	Hardcoded secret or API key committed → credential theft, unauthorised access	M	H	Developer error in fast sprints; git history persists after deletion without rotation.	Engineering Manager	✓ GitGuardian CI gate — detected secrets block push immediately + 48h rotation SLA (ISO 27001 A.8.12).	L
SD-04	Secure SDLC	Undisclosed vulnerability exploited by external researcher → reputational and regulatory damage	M	M	Without a published VDP, researchers have no coordinated channel — silent exploitation is the alternative.	Security Lead	✓ security.txt published (RFC 9116). ✓ Responsible Disclosure Policy at elogic.co/security. ✓ Annual pentest — exec summary under NDA via security@elogic.co.	L
QA-01	QA Automation	Regression defect at checkout reaching production → direct revenue loss	H	H	Checkout is highest-value, highest-risk flow; regression frequency increases with platform complexity.	QA Lead	✓ ISTQB-certified QA team. ✓ Test Strategy in SOW. ✓ Coverage thresholds in CI (≥80% critical modules). ✓ DoD with named QA sign-off. ✓ Defect escape rate tracked (Sev1 = 0 target).	M
QA-02	QA Automation	Performance regression post-release causing CWV decline → SEO loss, conversion drop	H	H	Google CWV directly correlates with organic traffic; undiscovered degradation compounds weekly.	QA Lead / DevOps	✓ Lighthouse CI (LCP ≤2.5s / CLS ≤0.1 / INP ≤200ms) — budgets committed to repo; build fails on breach.	M
QA-03	QA Automation	Flaky test suite masking real defects → false pass signals corrupting release gate	M	M	High test debt common in long-running Magento/headless builds; unreliable CI degrades team confidence.	QA Lead	✓ Formal flaky test quarantine policy: ≥3 failures in 50 runs = auto-quarantine + Jira ticket. 30-day fix-or-remove SLA. Weekly backlog review.	L
QA-04	QA Automation	Accessibility regression (WCAG 2.1 AA) to production → EAA legal exposure (EU)	M	M	EU Accessibility Act enforceable since June 28, 2025; penalties vary by member state and can reach up to €500,000 in some jurisdictions.	QA Lead	✓ axe-core in CI (WCAG 2.1 AA rule set); zero critical/serious violations = PR merge requirement (EAA — EU Accessibility Act / EN 301 549).	L
PB-01	Performance Budgets	Launch without validated performance baseline → CWV failure, SLA breach	H	H	Production diverges from staging without enforced CI budgets; regressions compound before detection.	Tech Lead / PM	✓ Lighthouse CI budgets in repo. ✓ Performance budget in SOW/MSA. ✓ New Relic Browser RUM (p75/p95 CWV). ✓ CWV tracked pre/post every launch.	M
PB-02	Performance Budgets	BFCM overload causing site unavailability → revenue loss, SLA breach, brand damage	H	H	Managed services retail clients face concentrated seasonal risk; single BFCM failure = months of revenue.	DevOps / PM	✓ Named BFCM runbook per client. ✓ k6 load tests at T-6 weeks (5–10× traffic simulation). ✓ Change freeze ~Nov 15 through post-Cyber Monday. ✓ New Relic Synthetics war room monitoring.	M
PB-03	Performance Budgets	Silent production CWV degradation between releases → gradual decline undetected	M	M	Without synthetic monitoring, degradation only caught at next manual audit cycle.	DevOps / QA	✓ New Relic Synthetics: 1-min uptime + 5-min multi-step journey checks, EU+US coverage, multi-location alerting.	L
PB-04	Performance Budgets	Third-party script regression degrading LCP/INP → client-side CWV decline	M	M	Tag manager proliferation is the primary CWV risk factor in enterprise retail.	Tech Lead	✓ New Relic Browser RUM p75/p95 CWV alerts at ‘Needs Improvement’ boundary. ✓ INP budget enforced in CI.	L
RM-01	Release Management	Incomplete P1 rollback capability → extended outage, data inconsistency, SLA breach	H	H	Complex Magento/composable builds have multiple deployment failure modes.	Engineering Manager	✓ P1 RTO ≤60 min. ✓ Platform rollback per spec (AC/Shopify/headless). ✓ LaunchDarkly kill-switch. ✓ 48h intensive hypercare post-launch.	M
RM-02	Release Management	Unauthorised change to production → data corruption, SOC 2 CC8.1 finding	H	H	Change control failure is the primary SOC 2 CC8.1 audit finding in technology vendor assessments.	PM / Engineering Manager	✓ Formal change advisory matrix. ✓ Trunk-based development (DORA 2024). ✓ Change log retained 3 years (SOC 2 CC8.1).	M
RM-03	Release Management	Production PII in staging → GDPR breach, DPA violation	M	H	Dev environments mirror production without automated masking unless explicitly governed.	Engineering Manager	✓ Automated data masking in staging (GDPR Art. 25; ISO 27001 A.8.31). No manual override permitted.	L
RM-04	Release Management	Emergency change during BFCM freeze → instability at highest-revenue window	M	H	Emergency bypass is the most common cause of peak-period incidents across managed services.	PM / Engineering Manager	✓ Change freeze ~Nov 15 – post-Cyber Monday. ✓ Break-glass: Incident Commander + client IT/Product owner approval + documented rollback plan required.	L

4. Control Detail: Domain 1 — Secure SDLC

4.1 Overview

This domain governs the security properties of software from requirements through deployment. For ecommerce platforms processing cardholder data, PII, and high-value B2B transactions, a breach attributable to a preventable development-phase vulnerability is both a commercial and regulatory event. Controls in this domain directly address PCI DSS v4.0 Requirement 6, ISO 27001:2022 Annex A.8.25–8.31, NIST SSDF SP 800-218, and SOC 2 CC8.1. All controls are ✓ CONFIRMED.

4.2 Control Inventory

C1.1 — Software Composition Analysis (SCA) — Snyk

✓ Snyk Open Source runs on every pull request and every nightly main-branch build. Severity gate: CVSS ≥7.0 (High/Critical) = build failure. Medium (4.0–6.9) = warning + tracked Jira ticket. Low (<4.0) = quarterly backlog. Standard: NIST SSDF SP 800-218 PW.4.4 (Reuse existing well-secured software). PCI DSS v4.0 Req 6.3.1, 6.3.2, 6.3.3.
✓ SBOM (Software Bill of Materials) generated in CycloneDX format per build, satisfying PCI DSS v4.0 Req 6.3.2 (maintained inventory of bespoke and custom software + third-party components). Standard: PCI DSS v4.0 Req 6.3.2, effective March 31 2025.
✓ Open-source licence policy: GPL and AGPL licences are blocked in commercial product code. MIT, Apache 2.0, and BSD are permitted. Enforced via Snyk licence policy. Standard: ISO 27001:2022 A.8.30 (Outsourced development / third-party components).

C1.2 — Pull Request Review Gates

✓ Branch protection requires ≥2 reviewers for production branches. Sensitive paths (payment, authentication, order processing, ERP integration) are enforced via CODEOWNERS files. All required status checks (SCA, tests) must pass before merge. Standard: ISO 27001:2022 A.8.25 (Secure development policy).

C1.3 — Secrets Detection — GitGuardian

✓ GitGuardian operates as a CI gate on every push. Detected secrets block the push or merge immediately. Incident workflow on detection: rotate credentials, invalidate tokens, conduct scope analysis within 48 hours. Standard: ISO 27001:2022 A.8.12 (Prevention of data leakage). GitGuardian serves 600,000+ developers; the platform detects 350+ secret types including Shopify, Adobe Commerce, and AWS credentials.

C1.4 — Vulnerability Remediation SLAs

Severity (CVSS)	SLA	Action	Standard
Critical (≥9.0)	≤24–48 hours	Patch or mitigate; re-scan to verify	✓ NIST SSDF SP 800-218 RV.1; ISO 27001 A.8.8
High (7.0–8.9)	≤7 days	Patched sprint; re-scan	✓ NIST SSDF; PCI DSS v4.0 Req 6.3.3
Medium (4.0–6.9)	≤30 days	Scheduled sprint; tracked ticket	✓ NIST SSDF SP 800-218; ISO 27001 A.8.8
Low (<4.0)	≤90 days	Quarterly backlog review	✓ NIST SSDF SP 800-218

✓ Temporary mitigations (WAF rules, feature flag disable, config change) are acceptable if patch lead-time exceeds SLA, but must be time-boxed with a named remediation due date. Standard: NIST SSDF SP 800-218 RV.1.

C1.5 — Penetration Testing

✓ Annual independent penetration test with full scope: OWASP Top 10 and OWASP API Security Top 10, authenticated and unauthenticated flows, payment gateway and checkout business logic, internal and external network layers, PCI DSS Req 11.4 surface. Conducted by an organizationally independent third party. Standard: PCI DSS v4.0 Req 11.4.2, 11.4.3 (annual + post-significant-change). OWASP Testing Guide v4.
✓ Retesting conducted after remediation of all Critical and High findings. Critical/High findings remediated within 30 days of report delivery. Standard: PCI DSS v4.0 Req 11.4.4.
✓ Executive summary of most recent pentest available under NDA for enterprise client due diligence. Request via security@elogic.co.

C1.6 — Responsible Disclosure Policy + security.txt

✓ security.txt published at elogic.co/.well-known/security.txt per RFC 9116 (April 2022). Required fields: Contact (security@elogic.co), Expires. Included fields: Policy, Encryption (PGP key), Preferred-Languages, Canonical, Acknowledgments. Standard: RFC 9116; ISO 27001:2022 A.8.8 (Management of Technical Vulnerabilities requires a public contact point for researchers).
✓ Responsible Disclosure Policy published at elogic.co/security. Policy covers: scope, reporting instructions, response SLAs (acknowledge ≤3 business days, triage ≤10 business days), legal safe harbor, credit policy for responsible reporters, exclusions. Standard: ISO/IEC 29147:2018 (Vulnerability Disclosure); ISO/IEC 30111 (Vulnerability Handling Processes).

C1.7 — Threat Modeling (STRIDE)

✓ Lightweight STRIDE threat modeling is performed for all Tier-1 projects (PCI scope, regulated industries, ≥5 API integrations) and high-risk features. Process: 60–90 minute Sprint 0 workshop with Data Flow Diagram (DFD) + trust boundary mapping + STRIDE enumeration. 15–30 minute delta reviews per sprint for new features. Standard: NIST SSDF SP 800-218 PW.1.1 (Use forms of risk modeling). ISO 27001:2022 A.8.25. OWASP Threat Modeling Cheat Sheet.
✓ Output artefact: threat enumeration table (Component → STRIDE Category → Threat → Severity → Mitigation → Owner → Status), linked Jira backlog items, decision log for accepted risks. Tooling: OWASP Threat Dragon (open source). Standard: OWASP Threat Modeling Cheat Sheet; Adam Shostack’s Four Question Framework.

4.3 Standards Alignment

ISO 27001:2022 — A.8.25–8.31 (Secure development lifecycle through environment separation)
NIST SSDF SP 800-218 — PW.1.1 (risk modeling), PW.4.4 (automated vulnerability detection), RV.1 (identify and confirm vulnerabilities)
PCI DSS v4.0 — Req 6.3.1–6.3.3 (vulnerability management), Req 11.4.2–11.4.4 (penetration testing)
SOC 2 — CC8.1 (Change management authorisation and documentation)
OWASP SAMM v2 — Implementation > Secure Build; Verification > Security Testing
RFC 9116 — security.txt file format for vulnerability disclosure
ISO/IEC 29147:2018 — Vulnerability disclosure processes

4.4 Buyer Proof Points

Request: security.txt at elogic.co/.well-known/security.txt — publicly verifiable, zero friction
Request: Responsible Disclosure Policy at elogic.co/security/ — publicly available
Request: Snyk SCA CI config (sanitised YAML) — confirms tooling in pipeline, not aspirational
Request: GitGuardian deployment confirmation — confirms secrets detection operational
Request: Penetration test executive summary (NDA) — contact security@elogic.co
Request: Vulnerability remediation SLA policy — confirms Critical ≤48h / High ≤7d commitments

5. Control Detail: Domain 2 — QA Automation

5.1 Overview

This domain governs systematic verification and validation of software quality throughout delivery. ISTQB-certified QA professionals are embedded from sprint zero through hypercare. ISO 9001:2015 Clause 8.6 requires a formal release gate; this domain specifies how that gate is implemented operationally across Elogic’s platform portfolio. All controls are ✓ CONFIRMED.

5.2 Control Inventory

C2.1 — Test Strategy Document

✓ A named Test Strategy document is a standardised, templated SOW line item on all new-build and re-platform engagements. It defines environments, test levels, entry/exit criteria, regression scope, and release gates. Produced per engagement, versioned, and retained in the project repository. Standard: ISTQB 4.0 (Test Planning); ISO 9001:2015 Cl. 8.5.1.

C2.2 — Code Coverage Thresholds (CI-Enforced)

✓ Coverage thresholds enforced in CI quality gates. Applied to custom code only (not vendor core). Standard: ISO 9001:2015 Cl. 8.6; ISTQB 4.0 guidance on test completeness.
Backend custom modules: ≥70% line / ≥60% branch
Critical modules (checkout, payment, order, ERP integration): ≥80% line / ≥70% branch
Frontend / headless: critical user journey E2E coverage enforced (E2E path coverage takes precedence over line %)

C2.3 — ISTQB Certification + Annual CPD

✓ ISTQB-certified QA professionals are embedded across delivery teams. ISTQB Foundation is the baseline for all QA engineers; QA Leads/Test Managers hold CTAL-TM (Advanced Test Manager) or equivalent advanced-level certification. Standard: ISTQB 4.0 Foundation and Advanced syllabi. ISTQB Foundation and Advanced certifications are valid for life (no expiry).
✓ Annual CPD review is conducted in Q4 per ISO 27001:2022 Clause 7.2. Minimum 20 hours per QA team member per year. Eligible activities: additional ISTQB specialist certifications (CT-TAE, CT-SEC, CTAL-TM), tool certifications (Playwright, Cypress), conference attendance, internal knowledge-sharing sessions, and industry reading. Competence tracked in a skills matrix mapping ISTQB knowledge areas to roles. Standard: ISO 27001:2022 Cl. 7.2; ISO 9001:2015 Cl. 7.2 (Competence).

C2.4 — Regression Suite + Flaky Test Quarantine Policy

✓ Regression suite execution frequency: per PR (unit + smoke E2E for critical paths); nightly (expanded regression E2E suite); pre-release (full regression + performance sanity + security checks). Standard: ISO 9001:2015 Cl. 9.1.1; SOC 2 CC7.2.
✓ Formal flaky test quarantine policy: detection threshold = ≥3 failures in last 50 runs OR >5% failure rate. On trigger: test is automatically quarantined (still runs, does not block CI), Jira ticket auto-created and assigned to code owner, Slack notification sent. Fix-or-remove SLA: 30 calendar days. Exit criteria: 10 consecutive passes required to leave quarantine. Weekly quarantine backlog review by QA Lead. Standard: Google Testing Blog (industry de facto standard); ISTQB 4.0 test repeatability guidance; DORA Change Failure Rate metric.
Tooling: BuildPulse or Datadog Test Visibility for automated flaky detection and quarantine management.

C2.5 — Performance Testing

✓ Lighthouse CI integrated in CI pipeline; budget configuration committed to repository. Thresholds: LCP ≤2.5s, CLS ≤0.1, INP ≤200ms (Google CWV ‘Good’ thresholds, web.dev/vitals March 2024). Build fails on Critical budget breach. Standard: ISO 9001:2015 Cl. 8.6.
Load testing with Grafana k6: pre-launch (mandatory, simulates 2–5× normal traffic) and pre-BFCM (mandatory for managed services clients, simulates 5–10× normal traffic). Grafana k6 is a widely adopted open-source load testing tool with native CI/CD integration.

C2.6 — Accessibility Testing (axe-core + EAA Compliance)

✓ axe-core integrated in CI pipeline with WCAG 2.1 AA rule set (tags: wcag2a, wcag2aa, wcag21a, wcag21aa). PR merge gate: zero critical or serious violations. During integration baseline period, advisory mode used for 2–4 weeks before gatekeeper mode activated. axe-core detects approximately 57% of WCAG issues automatically; manual audit conducted on every major release. Standard: EU Accessibility Act (Directive 2019/882), enforceable June 28 2025 across all 27 EU member states. EN 301 549 v3.2.1. WCAG 2.1 Level AA (W3C). Penalties vary by member state; in some jurisdictions fines can reach up to €500,000.
✓ eslint-plugin-jsx-a11y integrated in development environment for React/JSX stacks. Manual expert review and assistive technology testing on accessibility-critical engagements. Standard: WCAG 2.1 AA; W3C ACT Rules.

C2.7 — Defect Escape Rate KPI

✓ Defect escape rate (production defects discovered post-release / total defects in release) is tracked per sprint and reported in QBR. Sev1 (production outage / checkout failure) target = 0. Overall target: ≤5%. Standard: ISO 9001:2015 Cl. 9.1.1 (Monitoring and measurement); DORA Elite performer benchmark.

C2.8 — Definition of Done (Release Gate)

✓ Formal Definition of Done checklist with a named QA sign-off authority. Minimum gate: all planned test cases executed, zero open Critical/High defects, regression suite pass, Lighthouse CI budget pass, axe-core accessibility pass. Standard: ISO 9001:2015 Cl. 8.6 (Release of products and services); ISTQB exit criteria.

5.3 Standards Alignment

ISO 9001:2015 — Cl. 8.5.1, 8.5.4, 8.6, 9.1.1
ISO 27001:2022 — Cl. 7.2 (Competence)
SOC 2 — CC7.2 (System monitoring)
ISTQB 4.0 — Foundation + Advanced Test Manager syllabi
EU Accessibility Act 2025 — Directive 2019/882; EN 301 549; WCAG 2.1 AA
DORA 2024 — Change failure rate; deployment frequency benchmarks

5.4 Buyer Proof Points

Request: QA Test Strategy template — demonstrates ISTQB-aligned planning process
Request: Definition of Done checklist with named sign-off authority
Request: Defect escape rate KPI report (anonymised) — evidences sprint-level outcome measurement
Request: Lighthouse CI config + axe-core config from a recent project — confirms both gates operational
Request: Flaky test quarantine policy document — confirms formal written procedure
Request: ISTQB certification confirmation and CPD records — contact legal@elogic.co

6. Control Detail: Domain 3 — Performance Budgets

6.1 Overview

This domain governs systematic measurement and enforcement of front-end performance standards throughout development, at launch, and in production. Google Core Web Vitals (CWV) are the primary metric framework. A performance regression is a commercial event. Elogic tracks CWV KPIs before and after every launch (✓ publicly stated). This domain names the specific tooling, thresholds, contractual artefacts, and peak-traffic protocol behind that claim. All controls are ✓ CONFIRMED.

6.2 Control Inventory

C3.1 — Core Web Vitals (CWV) Targets

The three Core Web Vitals are: LCP (Largest Contentful Paint) — perceived load speed; CLS (Cumulative Layout Shift) — visual stability; INP (Interaction to Next Paint) — responsiveness. A fourth diagnostic metric, TTFB (Time to First Byte), measures server response speed. All four are tracked. Source: Google web.dev/vitals, thresholds updated March 2024.

Metric	‘Good’ Threshold	Measured At	Status
LCP (Largest Contentful Paint)	≤2.5 seconds	p75, field data	✓ Google CWV spec (web.dev/vitals, March 2024)
CLS (Cumulative Layout Shift)	≤0.1	p75, field data	✓ Google CWV spec
INP (Interaction to Next Paint)	≤200 milliseconds	p75, field data	✓ Google CWV spec (replaced FID March 2024)
TTFB (Time to First Byte)	≤800 milliseconds	p75, field data	✓ Google CWV spec

C3.2 — Performance Budget as Contract Artefact

✓ Performance budgets and monitoring are contractual deliverables for new builds and re-platforms. Acceptance criteria are named in the SOW/MSA schedule and tied to page templates (homepage, PDP, PLP, cart, checkout) and key business flows. Standard: ISO 9001:2015 Cl. 8.6 (Release acceptance criteria).

C3.3 — CI Enforcement (Lighthouse CI)

✓ Lighthouse CI budget configuration versioned in-repository on all new-build projects. Validated on every PR; Critical budget breach = build failure; advisory budget = warning. Standard: ISO 9001:2015 Cl. 8.5.1.

C3.4 — Synthetic Monitoring (New Relic Synthetics)

✓ New Relic Synthetics deployed post-launch: 1-minute uptime checks for critical endpoints + 5-minute multi-step critical journey checks (homepage → PDP → cart → checkout). Geographic coverage: minimum EU + US; expanded to top 2–4 revenue geos per client. Alerting requires multiple locations to fail before triggering to eliminate false positives. Standard: ISO 9001:2015 Cl. 9.1.1; SOC 2 A1.1 (Availability).

C3.5 — Real User Monitoring (New Relic Browser)

✓ New Relic Browser RUM deployed in production for managed services clients. Tracks p75 and p95 for LCP, CLS, INP, and TTFB. Alerts tied to Google ‘Needs Improvement’ boundary. CWV data reviewed in quarterly business review (QBR). Standard: ISO 9001:2015 Cl. 9.1.1.

C3.6 — BFCM Runbook + Peak-Traffic Protocol

✓ Named BFCM runbook maintained per managed services client with seasonal trading peaks. Runbook covers: timeline and milestones, client risk assessment, capacity planning with cloud auto-scaling configuration, change freeze policy, load test plan (k6 at T-6 weeks, 5–10× traffic simulation), monitoring and alerting thresholds, on-call rotation (primary + secondary per service area), incident response playbook, war room operations, vendor emergency contacts, rollback procedures, and post-mortem template. Standard: ITIL 4 Service Transition; ISO 9001:2015 Cl. 9.1.1.
✓ Change freeze: code freeze begins approximately 2 weeks prior to Black Friday (approximately November 15) through just after Cyber Monday. Break-glass exemption: Incident Commander + client IT/Product owner approval, documented in incident log within 24 hours. Permitted during freeze: content/CMS and promo configuration. Prohibited: library upgrades, schema changes, new integrations. Standard: Shopify partner guidance (~2-week code freeze pre-BFCM is the accepted market standard). ITIL 4 Emergency Change Management.

C3.7 — Budget Breach Escalation

✓ CWV breach (CI or synthetic) triggers: (1) automated New Relic alert to on-call engineer + PM; (2) incident created in tracking system within 1 hour; (3) root-cause investigation within 4 hours; (4) client communication within 2 business hours for managed services. Standard: ISO 9001:2015 Cl. 9.1.1; SOC 2 A1.1.

7. Control Detail: Domain 4 — Release Management + Rollback

7.1 Overview

This domain governs authorisation, execution, monitoring, and reversal of changes to production environments. SOC 2 CC8.1 and ISO 27001:2022 A.8.32 both require documented change control with evidence of authorisation. Elogic operates PMI-aligned governance (PMP®-certified PMs), trunk-based development (DORA 2024), LaunchDarkly feature flags, and automated data masking in staging (all ✓ confirmed). All controls are ✓ CONFIRMED.

7.2 Control Inventory

C4.1 — Branching Strategy (Trunk-Based Development)

✓ Default model: trunk-based development with short-lived feature branches. Release branches used when client governance requires staged promotion. Standard: DORA 2024 State of DevOps Report explicitly identifies trunk-based development as a key capability associated with higher delivery performance and lower change failure rates. This is Elogic’s standard model across Adobe Commerce, Shopify Plus, and headless stacks.

C4.2 — Environment Topology + Promotion Gates

✓ Standard topology: dev → staging → UAT → production. Gates: dev→staging requires automated test suite pass + code review; staging→UAT requires QA DoD sign-off + PM approval; UAT→production requires client sign-off (new builds) or change advisory approval (managed services) + all automated checks pass. Standard: ISO 27001:2022 A.8.31; ISO 9001:2015 Cl. 8.5.1.

C4.3 — Data Governance in Non-Production Environments

✓ Data masking in staging environments is automated (not manual). No production PII replicates to development or staging without automated masking applied. Masking scripts are per-platform and version-controlled. Standard: GDPR Art. 25 (Data protection by design and by default); ISO 27001:2022 A.8.31.

C4.4 — Feature Flag Governance (LaunchDarkly)

✓ LaunchDarkly deployed for feature flag management across production. Flags used for progressive rollout, risk isolation, and safer deployments. Flags are time-boxed (maximum lifetime defined per flag at creation) to prevent permanent codebase complexity. Emergency kill-switch: any on-call engineer can disable a flag during a P1 incident without change advisory approval. Standard: DORA 2024 and Atlassian cite feature flagging as a key low-risk deployment capability.

C4.5 — Deployment Strategy by Platform

✓ Adobe Commerce (Cloud): zero-downtime deployments following Adobe Cloud best practices; maintenance mode toggle available as fallback.
✓ Shopify Plus: theme deployments validated on unpublished/staging theme first; previous theme retained in library for instant rollback without re-deployment.
✓ BigCommerce: Stencil bundling automated via stencil push in CI/CD.
✓ Salesforce Commerce Cloud (SFCC): code uploaded to inactive code version on staging; replicated/promoted to production with standard versioning plan.
✓ commercetools / headless: CI/CD-oriented tooling with CI-friendly Merchant Center config sync and blue-green CDN deployments.

C4.6 — P1 Rollback SLA + Hypercare

✓ Committed P1 rollback RTO for managed services: ≤60 minutes. Target ≤30 minutes where architecture supports instant theme revert or LaunchDarkly kill-switch. Rollback procedure documented per platform and tested pre-launch. Standard: ISO 9001:2015 Cl. 8.5.6; ITIL 4 Major Incident Management.
✓ Post-launch hypercare: 48 hours intensive (dedicated on-call engineer, rapid response) + stabilisation period (2–4 weeks, business hours) depending on scope and SLA tier. Escalation triggers: P1/P2 incident, CWV breach, order volume anomaly, integration error rate spike. Standard: ITIL 4 Service Transition.

C4.7 — Incident Severity Matrix (P1–P4)

P	Category	Definition	Response / Resolution SLA	Standard
P1	Critical	Site down, checkout unavailable, active data breach	15 min response; ≤4h resolution target	✓ ISO 20000-1 Cl. 8.6; ITIL 4
P2	High	Major feature failure, payment degraded, <50% users impacted	1h response; ≤8h resolution	✓ ITIL 4 Major Incident
P3	Medium	Non-critical feature failure, workaround available	4h response; ≤2 business days	✓ ITIL 4
P4	Low	Cosmetic issue, no revenue impact	Next sprint planning	✓ ITIL 4

C4.8 — Change Advisory Process

✓ Formal change approval matrix documented for managed services. Standard changes (pre-approved, recurring, low-risk): PM approval + change log entry. Normal changes: request → risk assessment → PM + Tech Lead approval → scheduled window → deployment → post-deployment verification. Emergency changes: Tech Lead approval immediately; full review within 24 hours post-deployment. Standard: SOC 2 CC8.1; ISO 27001:2022 A.8.32.

C4.9 — Change Freeze + BFCM Policy

✓ Change freeze: ~November 15 through just after Cyber Monday + client-defined windows. Permitted during freeze: content/CMS updates and promo configuration. Prohibited: library upgrades, database schema changes, new third-party integrations. Break-glass: Incident Commander + client IT/Product owner approval, documented in incident log. Standard: ITIL 4 Emergency Change Management; Shopify partner guidance (market standard).

C4.10 — Change Log + Release Notes

✓ Change log maintained per release: release ID, date, change type, description, test evidence reference, approver, deployment engineer. Release notes distributed to client stakeholders within 24 hours of deployment. Retained minimum 3 years for audit purposes. Standard: SOC 2 CC8.1; ISO 27001:2022 A.8.32.

7.3 Standards Alignment

ISO 9001:2015 — Cl. 8.5.6 (Control of changes)
ISO 27001:2022 — A.8.32 (Change management), A.8.31 (Environment separation)
SOC 2 — CC8.1 (Change management: authorisation, testing, documentation)
DORA 2024 — Trunk-based development, deployment frequency, change failure rate
PMI PMBOK 7th Ed — Integrated change control (PMP®-certified PMs)
ITIL 4 — Major Incident Management, Emergency Change, Service Transition
ISO 20000-1:2018 — Cl. 8.6 (Incident management SLAs)
GDPR Art. 25 — Data protection by design (automated masking)

7.4 Buyer Proof Points

Request: Incident severity matrix document — confirms P1–P4 SLAs are formal, not verbal
Request: Change advisory process document — confirms formal matrix for managed services
Request: BFCM change freeze policy with start date and exemption authority
Request: P1 rollback procedure per platform — confirms documented and tested
Request: LaunchDarkly deployment evidence — confirms feature flag governance operational
Request: Sample change log / release notes (anonymised) — confirms documentation process

8. Standards Alignment Matrix

Domain	ISO 9001:2015	ISO 27001:2022 Annex A	SOC 2 TSC	PMI PMBOK	Other
Secure SDLC	—	A.8.8, A.8.12, A.8.25–8.31	CC8.1	—	NIST SSDF PW.1.1, PW.4.4, RV.1; PCI DSS v4.0 Req 6.3, 11.4; OWASP SAMM v2; RFC 9116; ISO/IEC 29147:2018
QA Automation	8.5.1, 8.5.4, 8.6, 9.1.1	Cl. 7.2 (Competence)	CC7.2	Quality Mgmt	ISTQB 4.0; EU Accessibility Act / EN 301 549; DORA 2024; Google SRE flaky tests
Performance Budgets	8.6, 9.1.1	A.8.6 (Capacity)	A1.1	—	Google CWV (web.dev/vitals Mar 2024); ITIL 4; DORA 2024
Release Management	8.5.6	A.8.31, A.8.32	CC8.1	PMBOK Change Control	DORA 2024 (trunk-based dev); ITIL 4; ISO 20000-1 Cl. 8.6; GDPR Art. 25

9. Applicability & Exceptions

9.1 Universal Controls (All Engagements)

The following controls apply to every Elogic engagement regardless of scope, platform, or contract value:

GitGuardian secrets detection on all repositories
≥2 reviewer PR gate with CODEOWNERS on all production branches
Vulnerability remediation SLAs (Critical ≤48h / High ≤7d / Medium ≤30d / Low ≤90d)
Lighthouse CI performance budgets committed to repository on all new-build and re-platform projects
axe-core accessibility CI gate (WCAG 2.1 AA) on all new-build and re-platform projects
Trunk-based development as default branching model
≥2 reviewer PR gate, automated test suite pass, and QA DoD sign-off as release gates
Automated data masking in all non-production environments
Change log maintained per release with 3-year retention

9.2 Managed Services Controls

The following controls apply to engagements operating under a Managed Services Agreement (MSA) with a defined SLA tier:

New Relic Synthetics monitoring (1-min uptime + 5-min critical journey checks)
New Relic Browser RUM (p75/p95 CWV tracking)
LaunchDarkly feature flag governance
Formal P1–P4 incident severity matrix with committed response and resolution SLAs
48-hour intensive hypercare post-launch + stabilisation period
BFCM runbook + change freeze policy (~November 15 through post-Cyber Monday)
Formal change advisory process (standard, normal, and emergency change classification)

9.3 Tier-1 Project Controls

The following controls apply to Tier-1 projects as defined on the cover page (PCI scope, regulated industry, ≥5 integrations, enterprise SLA tier, or >€10M GMV):

STRIDE threat modeling: Sprint 0 workshop + per-sprint delta reviews
Annual independent penetration test with OWASP Top 10 + API Security Top 10 scope
SBOM generation in CycloneDX format per build (PCI DSS v4.0 Req 6.3.2)
Snyk SCA with CVSS-threshold CI gate (≥7.0 = build failure)

9.4 Client Tooling Constraints

Where a client’s existing infrastructure or contractual obligations require deviation from Elogic’s standard tooling (e.g., a mandated alternative to New Relic, or a client-managed CI/CD pipeline), the following process applies:

Deviation documented in the engagement SOW as a named exception
Equivalent control identified and documented (same control objective achieved via alternative tool)
Risk acceptance signed by both the client’s authorised representative and Elogic’s Engineering Manager
Exception reviewed at each annual document review cycle

9.5 Waiver and Risk Acceptance Process

Any control in this document may be subject to a formal risk acceptance in lieu of implementation, subject to the following conditions:

Written risk acceptance prepared by the Elogic Engineering Manager or QA Lead
Risk acceptance documents: control reference, risk description, compensating control (if any), residual risk rating, and review date (maximum 12 months)
Risk acceptance signed by Paul Okhrem (Co-Founder & CEO) or Igor Iakovliev (Co-Founder)
Risk acceptance retained for the duration of the engagement + 3 years
Risk acceptances are not disclosed externally; their existence is disclosed in enterprise due diligence responses on request

10. Additional Control Domains

This document governs four engineering control domains. Two additional domains — Access Control and Business Continuity / Disaster Recovery — are addressed in dedicated policy documents. Enterprise clients conducting vendor due diligence may request these documents via legal@elogic.co.

10.1 Access Control (ISMS Policy)

Elogic’s Access Control policy governs the following areas. Enterprise clients may request the full policy document under NDA.

✓ Multi-factor authentication (MFA) enforced on all production systems, source code repositories, cloud infrastructure, and internal tooling. Standard: ISO 27001:2022 A.9.4; SOC 2 CC6.1.
✓ Role-based access control (RBAC) with least-privilege principle applied to all system and application access. Access reviews conducted quarterly. Standard: ISO 27001:2022 A.5.15, A.5.18; SOC 2 CC6.3.
✓ Privileged access management (PAM): production access is time-limited, logged, and requires a named approval for each session. Standard: ISO 27001:2022 A.8.2; SOC 2 CC6.1.
✓ Centralised audit logging for all production access events, retained for a minimum of 12 months, with 90-day hot storage for active investigation. Standard: ISO 27001:2022 A.8.15; SOC 2 CC7.2.
✓ Joiners / Movers / Leavers (JML) process: access provisioned within 1 business day of onboarding; access fully revoked within 1 business day of offboarding, with immediate revocation for involuntary departure. Standard: ISO 27001:2022 A.5.18; SOC 2 CC6.2.

10.2 Backup, Recovery, and Business Continuity (BC/DR Policy)

Elogic’s BC/DR policy governs the following areas for managed services engagements. Enterprise clients may request the full policy document under NDA.

✓ Automated backups of all managed client databases and application state, with retention of at least 30 days. Backup integrity verified via automated restore tests. Standard: ISO 27001:2022 A.8.13; SOC 2 A1.2.
✓ Recovery Point Objective (RPO): ≤4 hours for managed services clients on standard SLA tier; ≤1 hour for enterprise SLA tier. Standard: ISO 27001:2022 A.5.30; SOC 2 A1.2, A1.3.
✓ Recovery Time Objective (RTO): ≤4 hours for managed services clients on standard SLA tier; ≤1 hour for P1 incidents on enterprise SLA tier. Standard: ISO 27001:2022 A.5.30; ITIL 4; SOC 2 A1.3.
✓ Business Continuity Plan (BCP) documented and tested annually. DR tabletop exercise conducted annually. Standard: ISO 27001:2022 A.5.29, A.5.30; ISO 22301; SOC 2 A1.3.
✓ Multi-region infrastructure for managed services clients with defined failover procedures. Cloud provider SLA compliance monitored continuously via New Relic. Standard: ISO 27001:2022 A.8.14 (Redundancy); SOC 2 A1.1.

Note: RPO/RTO commitments are defined per engagement in the Managed Services Agreement (MSA). Clients requiring specific RPO/RTO thresholds beyond the standard tier should raise this during commercial negotiation. Contact legal@elogic.co to request the full BC/DR Policy document.

11. Proof Inventory Checklist (Procurement-Facing)

Send requests to legal@elogic.co or security@elogic.co. NDA required for pentest and engagement-specific materials.

Artefact	Tier	Format	How to Request	Availability
Quality Policy Statement	✓	Web/PDF	elogic.co/quality-policy-statement/	Public — no request required
Code of Conduct	✓	Web/PDF	elogic.co/code-of-conduct/	Public — no request required
security.txt (RFC 9116)	✓	Text	elogic.co/.well-known/security.txt	Public — no request required
Responsible Disclosure Policy	✓	Web	elogic.co/security/	Public — no request required
Adobe Solution Partner (Silver) + Specializations (Americas & EMEA)	✓	Web	Adobe Partner Directory	Public — no request required
Shopify Plus Partner	✓	Web	Shopify Partner Directory	Public — no request required
BigCommerce Partner	✓	Web	BigCommerce Partner Directory	Public — no request required
Salesforce AppExchange Consulting Partner	✓	Web	AppExchange Listing	Public — no request required
Hyva Certified Technical Partner	✓	Web	Hyvä Partner Listing	Public — no request required
Stripe Partner Directory	✓	Web	Stripe Partner Directory	Public — no request required
Clutch — Premier Verified (2025); #1 Adobe Commerce Feb 2026	✓	Web	Clutch Profile	Public — no request required
G2 Reviews	✓	Web	G2 Reviews	Public — no request required
Snyk SCA CI config (sanitised)	✓	YAML	security@elogic.co	Internal — available on request
GitGuardian deployment confirmation	✓	Config	security@elogic.co	Internal — available on request
Penetration test executive summary (NDA)	✓	PDF (NDA)	security@elogic.co	Internal — NDA required
Vulnerability remediation SLA policy	✓	PDF	legal@elogic.co	Internal — available on request
QA Test Strategy template	✓	DOCX	legal@elogic.co	Internal — available on request
Flaky test quarantine policy	✓	DOCX	legal@elogic.co	Internal — available on request
axe-core CI config (recent project)	✓	YAML	legal@elogic.co	Internal — available on request
Lighthouse CI budget config (recent project)	✓	JSON	legal@elogic.co	Internal — available on request
Definition of Done checklist	✓	DOCX	legal@elogic.co	Internal — available on request
Defect escape rate KPI report (anon.)	✓	PDF	legal@elogic.co	Internal — available on request
ISTQB certification confirmation + CPD records	✓	PDF	legal@elogic.co	Internal — available on request
ISO 27001 certificate (Information Security)	✓	PDF	legal@elogic.co	Internal — available on request
SOC 2 Type II report	✓	PDF (NDA)	legal@elogic.co	Internal — NDA required
ISO 9001 certificate (Quality Management)	✓	PDF	legal@elogic.co	Internal — available on request
Incident severity matrix (P1-P4)	✓	PDF	legal@elogic.co	Internal — available on request
BFCM runbook template	✓	PDF	legal@elogic.co	Internal — available on request
Change advisory process document	✓	PDF	legal@elogic.co	Internal — available on request
BFCM change freeze policy	✓	PDF	legal@elogic.co	Internal — available on request
P1 rollback procedure (per platform)	✓	PDF	legal@elogic.co	Internal — available on request
New Relic Synthetics dashboard (anon.)	✓	Screenshot	legal@elogic.co	Internal — available on request
Sample change log / release notes (anon.)	✓	PDF	legal@elogic.co	Internal — available on request

12. Document Control

Document	Elogic Commerce Risk Register + Engineering Controls
Version	v3.0
Date Created	February 27, 2026
Review Cadence	Annual
Document Owner (DRI)	Paul Okhrem, Co-Founder & CEO
Signing Authority	Paul Okhrem, Co-Founder & CEO \| Igor Iakovliev, Co-Founder
Security Contact	security@elogic.co
Compliance Contact	legal@elogic.co
Parent Document	elogic.co/quality-policy-statement/
Publication URL	elogic.co/risk-register/
Open Gaps	None — all controls ✓ CONFIRMED
Publication Status	APPROVED — ready for publication

Frameworks Referenced:

This document is approved for external publication. All controls stated as ✓ CONFIRMED are in operation and evidenced against the named public standards. Evidence of specific controls is available upon request from enterprise clients conducting vendor due diligence.