Trust should be inspectable, not assumed.

The KOMERRA Trust Centre provides a consolidated explanation of the security, privacy, responsible-AI, data-governance, payment-integrity, reliability, and accountability practices supporting the KOMERRA platform.

It is intended to help businesses, customers, partners, advisers, auditors, regulators, and other stakeholders understand how KOMERRA approaches trust and where additional policies or assurance information can be found.

Trust should be based on inspectable controls, accurate documentation, responsible operations, and evidence—not broad claims, unexplained badges, or the assumption that any internet-connected service is impossible to compromise.

This Trust Centre should be read together with the KOMERRA Security & Trust page, Privacy Policy, Terms of Service, Data Processing Agreement, Data Retention Policy, Cookie Policy, Subprocessors page, Account Deletion Policy, Acceptable Use Policy, Responsible Disclosure Policy, and other applicable notices.

KOMERRA is operated by KOMERRA Technologies Limited, a company registered in the Federal Republic of Nigeria with registration number 9681120.

KOMERRA provides AI-assisted business-management technology for businesses, their Authorized Users, and Business Customers interacting through supported customer-facing services such as Mini Stores and Trust Passports.

Questions about trust, security, privacy, responsible AI, assurance, or provider governance may be sent to support@komerra.app.

Security reports should include “Security Report” in the subject. Privacy requests should include “Privacy Request”. Enterprise assurance or due-diligence requests should include “Trust and Assurance Request”.

KOMERRA’s trust programme is guided by layered protection, minimum necessary access, verification before trust, accountable human approval, evidence for sensitive activity, honest assurance language, and continuous improvement.

No single safeguard is treated as sufficient. Authentication does not replace authorization. Application permission checks do not replace tenant-aware data controls. A browser redirect does not replace payment-provider verification. AI confidence does not replace human judgment. A backup does not replace tested recovery.

Security and privacy controls must be reflected in the production platform, operating procedures, provider arrangements, staff responsibilities, monitoring, testing, and incident response—not merely described in policies or architecture diagrams.

A control should be described as implemented only when the corresponding production behaviour, configuration, workflow, or operating process has been verified.

Some controls may apply only to designated services, data categories, providers, environments, plans, or workflows. A control operating in one area should not be interpreted as automatically applying to every system unless that scope has been confirmed.

KOMERRA may use terms such as implemented, partially implemented, planned, under review, externally managed, or independently assessed when publishing detailed control-status information.

Where a material statement in this Trust Centre changes because a feature, provider, architecture, or control changes, the published information should be updated within a reasonable period.

Internal engineering intent, a code comment, an unfinished feature, or a development branch is not treated as evidence that a control is operating in production.

KOMERRA uses a layered security model intended to reduce the possibility that a weakness in one component becomes unrestricted access to the broader platform.

Relevant layers may include authentication, session controls, Workspace membership, role-aware authorization, tenant context, application validation, database controls, private service communication, object-storage authorization, provider verification, rate limits, monitoring, and audit records.

Protected operations should be evaluated using trusted server-side information rather than depending solely on identifiers, amounts, roles, status values, or other claims submitted by a browser or client application.

Internal services, workers, and schedulers should receive only the tenant identity, permissions, credentials, and information reasonably required to perform the requested operation.

Security boundaries must include background jobs, administrative tools, file access, exports, webhooks, support operations, internal services, queues, and automated workflows—not only customer-facing API routes.

KOMERRA’s authentication controls are designed to establish that a user has access to an approved credential before granting Account access.

Authentication controls may include password hashing, email verification, one-time codes, multi-factor authentication, passkeys, device authentication, session expiration, refresh-token rotation, credential revocation, recovery controls, and additional verification following suspicious activity.

Passwords should be protected using a strong one-way password-hashing algorithm rather than reversible encryption or plain-text storage.

Authentication secrets, recovery credentials, signing keys, access tokens, and similar security material should not be stored in source code, public client bundles, ordinary logs, or unsecured business records.

Repeated failed authentication attempts, suspected refresh-token reuse, unusual session behaviour, credential exposure, or other risk signals may result in temporary restriction, session revocation, credential reset, or additional verification.

Where available, KOMERRA may support passkeys, fingerprint unlock, facial unlock, security keys, or similar device-assisted authentication methods.

For ordinary passkey or device-biometric authentication, the user’s fingerprint or facial template is generally evaluated by the device, browser, operating system, or credential provider rather than being transmitted to KOMERRA.

KOMERRA ordinarily receives a cryptographic authentication result, credential identifier, public-key information, or similar assertion rather than the raw biometric template.

Device authentication is distinct from identity verification. A separate identity-verification process may involve a facial image, identity document, liveness result, or verification provider and must have an appropriate purpose, privacy notice, lawful basis, access restriction, and retention rule.

Users remain responsible for protecting their devices, recovery methods, email Accounts, telephone numbers, passkeys, and other authentication mechanisms.

Successfully logging in does not provide unrestricted authority across KOMERRA.

Protected access should be evaluated according to the authenticated user, active session, Workspace membership, tenant context, assigned role, explicit permission, requested action, affected resource, and applicable business rules.

Workspace owners are responsible for assigning staff roles that reflect genuine responsibilities and for removing or reducing access when a person’s role changes.

KOMERRA personnel, services, jobs, and providers should receive only the access reasonably necessary to perform their authorized functions.

Sensitive administrative actions should be limited to designated roles and should create appropriate activity or audit records.

Support access should not be treated as unrestricted production access and should be controlled according to legitimate need, authorization, confidentiality, and accountability requirements.

KOMERRA is a multi-tenant platform. The private records of one business must not become available to another business merely because both businesses use the same application or infrastructure.

Tenant-aware application authorization is intended to verify the relevant Workspace before protected information is read, changed, exported, transmitted, or deleted.

Database row-level security or comparable tenant-aware database controls may provide an additional boundary behind application code for designated tables and access paths.

Tenant isolation must also be enforced across object storage, background jobs, search, analytics, caches, queues, notifications, documents, exports, connected channels, support tools, and administrative interfaces.

Privileged database credentials, maintenance operations, migration processes, internal jobs, and service connections require additional scrutiny because some privileged access paths may not be restricted in the same way as ordinary application roles.

Tenant-isolation testing should include attempts to access another Workspace by changing identifiers, reusing file references, manipulating API parameters, invoking background tasks, or using administrative and export paths.

Information submitted through a browser, application, connected provider, webhook, import, file, or API is treated as untrusted until it has been validated.

KOMERRA should apply server-side validation to identifiers, types, formats, amounts, permissions, resource ownership, tenant context, state transitions, file attributes, callback authenticity, and other security-relevant information.

Client-side validation improves usability but is not treated as a security boundary because client code and browser requests can be modified.

Sensitive business rules—such as who may change a record, whether an order belongs to a Workspace, whether Credits are sufficient, or whether a payment is verified—must be enforced by trusted server-side logic.

Unexpected or invalid requests may be rejected, logged, rate-limited, or escalated for additional security review.

KOMERRA may apply route-specific, identity-specific, tenant-specific, device-aware, provider-aware, or risk-based limits to protect availability and reduce abuse.

Higher-risk routes may include signup, login, password recovery, verification, invitations, file uploads, AI actions, billable actions, payment verification, public forms, exports, and administrative operations.

Rate limits are one control among several and do not replace authentication, authorization, fraud detection, provider verification, or human review.

Limits may be adjusted according to provider requirements, plan, workload, Account history, system capacity, or identified abuse patterns.

Attempts to evade rate limits through multiple Accounts, rotating identifiers, automated clients, coordinated requests, or other techniques may result in restriction or suspension.

Supported production traffic is intended to use modern transport encryption between browsers, applications, APIs, infrastructure, and approved providers.

Managed databases, object storage, backups, and other infrastructure may provide encryption at rest as part of their service configuration.

Encryption does not replace access control, secure credential management, tenant isolation, monitoring, retention, or the need to minimize sensitive information.

Private internal services should use authenticated connections and private networking where supported and operationally appropriate.

Cryptographic keys, API secrets, webhook secrets, database credentials, and similar material should be stored through protected environment or secret-management systems and rotated when exposure or another material risk is identified.

Uploaded files may include business logos, profile images, product images, documents, customer attachments, payment evidence, identity documents, and other Business Content.

Private files should be associated with the correct Workspace and accessed through an authorized request or time-limited signed access rather than relying on a permanently public and predictable storage path.

File controls may include type validation, size limits, authorization checks, metadata validation, malware scanning, content restrictions, randomized storage keys, signed upload or download requests, and lifecycle rules.

A public product image and a private identity document require different access, caching, and retention treatment.

Possession of a file URL or identifier should not, by itself, grant access to a private file.

Deleted files may remain temporarily in protected backups according to the applicable backup and retention schedule.

KOMERRA distinguishes customer payments made directly to a business from payments made to KOMERRA for Credits, subscriptions, or other paid platform services.

For customer sales, KOMERRA may record an order, display payment instructions, store uploaded payment evidence, or assist with payment-status administration. The business must independently confirm settlement through its bank or authorized payment provider.

A screenshot, transfer receipt, debit alert, payment claim, browser message, or AI extraction is not treated as conclusive evidence that funds settled or cannot be reversed.

For KOMERRA Credit purchases or other platform payments, a client-side redirect or success page must not independently create Credits or paid entitlement.

The backend should verify the transaction through the payment provider’s trusted server-side interface and reconcile the reference, Account, amount, currency, status, and other material transaction details.

Duplicate callbacks, reused references, mismatched values, reversed transactions, forged events, or unverified claims must not create duplicate Credits or benefits.

KOMERRA seeks to minimize direct receipt, processing, transmission, and storage of payment-card account data by using established payment providers and hosted or tokenized payment workflows where available.

Payment-card numbers, card security codes, and similar payment credentials should be entered into the payment provider’s approved interface rather than ordinary KOMERRA forms, logs, support channels, or Business Content fields.

Using a payment provider does not automatically make every part of KOMERRA compliant with the Payment Card Industry Data Security Standard, nor does it automatically remove all responsibilities that may apply to KOMERRA or a business.

PCI DSS scope depends on the actual flow of payment account data, integration method, systems involved, contractual responsibilities, and applicable validation requirements.

KOMERRA should not claim PCI DSS compliance, certification, validation, or a particular scope unless the applicable assessment, provider evidence, or required validation has been completed and remains current.

A webhook or provider callback crosses an external security boundary and is not trusted merely because it reaches a documented endpoint.

Supported payment and integration webhooks should be checked using the provider’s applicable signature, secret, certificate, timestamp, reference-verification, or other approved authenticity mechanism.

Webhook processing should be idempotent so repeated delivery of the same valid event does not create duplicate Credits, records, notifications, financial effects, or state changes.

Sensitive events should be reconciled against expected information, such as the provider, transaction reference, Account, Workspace, amount, currency, event type, status, and prior processing state.

Invalid signatures, malformed payloads, unknown references, replay attempts, amount mismatches, duplicate events, and processing failures should create appropriate security or operational records.

Webhook verification should not be disabled in production merely because an event originates from a known provider or because development and testing workflows use different controls.

KOMERRA uses AI-assisted capabilities to extract, organize, summarize, classify, translate, recommend, and draft business information.

AI systems are treated as assistance layers rather than authoritative sources for tenant identity, user permission, payment settlement, Credit balances, stock movements, final prices, taxes, legal obligations, or other trusted platform state.

Trusted calculations and state changes should be performed or validated through deterministic application logic, authoritative records, provider results, and configured business rules.

An AI feature must not bypass Workspace permissions, tenant boundaries, approval requirements, usage limits, security controls, or provider verification.

AI Output can be inaccurate, incomplete, duplicated, biased, outdated, or unsuitable and must be reviewed according to the significance of the action.

Confidence indicators help prioritize review but do not convert uncertain Output into independently verified fact.

High-impact external, financial, destructive, permission-changing, security-sensitive, or publication actions should require meaningful authorization and appropriate human review.

Depending on the workflow, sensitive actions may include sending a customer communication, recording a payment, confirming an order, issuing a final receipt, publishing information, changing staff access, deleting records, or creating a material business commitment.

A confirmation interface should present the material information that the user needs to review, such as the customer, recipient, items, quantities, amounts, payment status, document type, affected records, or intended action.

Confirmation should not be presented in a misleading way or designed to hide important consequences.

The person approving an action remains responsible for reviewing the original information and ensuring that the action is appropriate for the business.

Only information reasonably necessary for an AI-assisted request should be submitted to the selected model or processing provider.

KOMERRA may use redaction, field selection, prompt controls, context limits, provider restrictions, safety controls, or other measures to reduce unnecessary disclosure.

Identifiable private Workspace Content should not be used to train unrelated general-purpose AI models unless the Workspace owner knowingly and expressly opts into a separately explained programme.

AI providers do not receive authority to act for a business merely because they process information for a requested function.

Provider selection should consider data usage terms, retention, security, privacy, service location, model behaviour, incident handling, and the nature of the information involved.

Material AI-provider involvement should be disclosed through the Privacy Policy, Data Processing Agreement, Subprocessors page, or other applicable notice.

AI-assisted functionality should be evaluated using representative business scenarios, supported languages, mixed-language inputs, low-quality images, ambiguous messages, voice notes, edge cases, and adversarial instructions.

Testing should assess extraction accuracy, false positives, false negatives, unsafe Output, hallucination, incorrect recipients, permission bypass attempts, tenant leakage, prompt injection, and inappropriate automation.

Material AI errors should be traceable to the relevant workflow, model or provider, version, configuration, request identifier, and available user correction where appropriate.

Users should be able to reject or correct material AI Output before approval in workflows requiring confirmation.

Changes to models, prompts, providers, confidence thresholds, validation rules, or automation should be evaluated according to the risk of the affected workflow.

KOMERRA’s privacy programme is designed to support lawful, fair, transparent, and purpose-limited processing of personal data.

The Privacy Policy explains the categories of information processed, the purposes, lawful bases, recipients, international transfers, retention approach, security safeguards, individual rights, and contact process.

For Account administration, billing, security, verification, support, and platform operations, KOMERRA may act as a data controller.

For customer, staff, supplier, order, communication, and other information placed in a business Workspace, the business generally acts as the data controller and KOMERRA generally processes the information on the business’s instructions.

The precise roles and responsibilities may depend on the relevant processing purpose and feature.

Privacy controls should include data minimization, access restriction, retention rules, provider governance, data-subject request handling, incident response, and privacy review for higher-risk features.

KOMERRA’s privacy and data-governance programme is designed to support applicable obligations under the Nigeria Data Protection Act 2023 and related regulatory guidance.

This includes attention to lawful processing, transparency, purpose limitation, data minimization, accuracy, storage limitation, security, accountability, data-subject rights, cross-border transfers, processor governance, and personal-data incident response.

Designing a service with these obligations in mind does not itself constitute certification, regulatory approval, a legal opinion, or proof that every implementation and processing activity is compliant.

Compliance depends on the actual data flows, purposes, providers, configurations, contracts, retention periods, security controls, operational behaviour, and responsibilities of both KOMERRA and the businesses using the platform.

Formal regulatory registrations, filings, assessments, designations, or audit outcomes should be described separately and precisely where applicable.

Personal data and Business Content should be retained only for as long as reasonably necessary for the relevant purpose, service delivery, security, fraud prevention, legal compliance, accounting, dispute handling, or exercise of legal rights.

Different categories of information require different retention periods. Account information, Workspace records, files, payment records, verification data, audit events, support records, diagnostics, and backups should not be governed by one indefinite retention rule.

The Data Retention Policy should describe applicable categories, retention periods or criteria, deletion triggers, legal holds, archival treatment, and backup handling.

Account or Workspace deletion may be subject to ownership verification, export opportunities, fraud investigation, payment records, statutory retention, security evidence, backup schedules, and another person’s rights.

Deleted information may remain temporarily in protected backups until the relevant backup expires or is securely overwritten.

Deletion workflows should cover databases, object storage, search indexes, caches, queues, analytics systems, support systems, and providers where applicable.

Critical activity should create evidence sufficient to support investigation, accountability, troubleshooting, and administrative review.

Relevant events may include login attempts, session creation and revocation, password or passkey changes, Account lockouts, verification changes, permission changes, staff invitations, Credit movements, payment verification, webhook rejection, record deletion, export activity, and privileged administrative actions.

Audit records should identify the acting identity or service, affected Workspace or resource, action, time, result, and relevant request or event reference where appropriate.

Audit records must themselves be protected against unauthorized access, manipulation, and unnecessary disclosure.

Auditability does not mean that every mouse movement, message, or ordinary action is retained indefinitely. Logging should remain proportionate, purposeful, privacy-aware, and subject to retention rules.

KOMERRA may use service-health monitoring, error monitoring, performance telemetry, security alerts, queue visibility, request identifiers, and privacy-configured interaction diagnostics to identify failures and risks.

Monitoring may cover authentication anomalies, unusual request patterns, elevated error rates, service outages, queue backlogs, provider failures, failed jobs, invalid webhooks, resource pressure, and deployment regressions.

Diagnostic tools should be configured to mask or exclude passwords, authentication secrets, full payment credentials, government identifiers, private keys, and other designated sensitive information.

Session replay or similar interaction reconstruction should only be used with appropriate privacy configuration, access restriction, retention, and consent where required.

A request identifier may help connect a user-visible failure with relevant server logs without exposing sensitive internal details to the user.

KOMERRA’s vulnerability-management process should address application code, dependencies, runtime versions, operating environments, containers, cloud configuration, databases, access policies, provider integrations, and exposed credentials.

Security updates should be prioritized according to exploitability, severity, affected information, exposure, available mitigations, and business impact.

Dependencies and runtimes that are unsupported, abandoned, materially vulnerable, or unnecessary should be upgraded, replaced, isolated, or removed.

Material security changes should be tested before production deployment and monitored after release.

A vulnerability-management programme should include remediation ownership, target dates, exceptions, evidence, retesting, and escalation for overdue high-risk findings.

Automated scanning is useful but does not replace architecture review, authorization testing, tenant-isolation testing, business-logic testing, or skilled human assessment.

Security should be considered during design, implementation, review, testing, deployment, and maintenance.

Material changes should undergo appropriate code review, automated checks, tests, migration review, configuration validation, dependency review, and deployment monitoring.

High-risk changes may require additional review of authorization, tenant isolation, payment integrity, AI approval, personal data, destructive operations, or provider callbacks.

Development and test environments should use separated credentials and should avoid unnecessary production personal data.

Production secrets must not be committed to source control or exposed through public environment variables, client-side bundles, build logs, screenshots, or documentation.

Emergency fixes should still be documented, reviewed after deployment, and followed by corrective testing where the urgency prevented the ordinary process.

Administrative access creates elevated risk and should be limited to authorized personnel with a legitimate operational, security, compliance, or support purpose.

Privileged actions affecting Accounts, businesses, verification, Credits, security controls, access, or protected records should be logged and reviewable.

Support personnel should not request a user’s password, private authentication key, card security code, or other secret that is unnecessary to provide support.

Where impersonation or support-assisted access is available, it should be restricted, visible, attributable, time-bounded where appropriate, and designed to avoid bypassing tenant controls.

Emergency privileged access should be exceptional, justified, monitored, and reviewed after use.

Former personnel and contractors should have access removed promptly when access is no longer required.

KOMERRA may rely on managed providers for hosting, databases, queues, object storage, networking, deployment, monitoring, communications, verification, AI processing, and payments.

Use of managed infrastructure does not transfer KOMERRA’s responsibility to select providers appropriately, configure services securely, restrict credentials, monitor relevant risks, and maintain suitable contractual protections.

Provider evaluation may consider security capability, privacy terms, service location, availability, data access, incident response, subcontractors, resilience, deletion, audit information, and integration risk.

Provider credentials should be scoped to the minimum necessary permissions and separated between development, test, staging, and production where appropriate.

A provider’s certification or assurance report applies to the provider’s stated system and scope; it does not automatically certify KOMERRA’s application, configuration, operating procedures, or end-to-end service.

Material providers processing personal data on behalf of KOMERRA should be identified through the Subprocessors page, Data Processing Agreement, Privacy Policy, or an applicable enterprise agreement.

The published information may include the provider, service category, processing purpose, and relevant processing location where appropriate.

Provider lists may change as services are added, replaced, relocated, or discontinued.

Material changes should be communicated according to applicable contractual and legal requirements.

The Subprocessors page should reflect providers actually used in production rather than listing planned, unused, expired, or development-only providers without explanation.

Security includes the availability and integrity of systems needed to support business operations.

KOMERRA may monitor application health, service latency, error rates, queue backlogs, failed jobs, provider availability, database connectivity, resource use, deployment health, and integration status.

The Service Status page should provide current or recent information about material service availability, degradation, maintenance, and resolved incidents where appropriate.

A service status statement should distinguish a confirmed incident from an unverified customer-specific issue or third-party provider problem.

Application errors should provide safe recovery guidance and a request identifier where useful without exposing stack traces, secrets, internal infrastructure, or private information.

Availability targets or service-level commitments apply only where expressly stated in the relevant plan or signed agreement.

Critical managed information should be covered by backup, snapshot, restoration, or recovery arrangements proportionate to the relevant service and risk.

A backup is useful only if it is protected, retained for an appropriate period, and capable of being restored when needed.

Recovery procedures should address applications, databases, queues, files, object storage, credentials, configuration, deployment state, and dependent providers where relevant.

Restore tests should be performed at a frequency proportionate to the importance and change rate of the affected systems.

Recovery procedures should account for data integrity, tenant boundaries, deletion records, security restrictions, and the possibility that compromised credentials or configurations must not be restored unchanged.

Businesses remain responsible for maintaining their own exports, accounting records, statutory records, and operational fallback procedures where appropriate.

KOMERRA may use workers, queues, schedulers, retries, and background processes for notifications, integrations, documents, AI tasks, payment events, reports, follow-ups, and other operations.

Background work must preserve the correct tenant, user authority, permission context, and resource ownership.

Idempotency and deterministic job identifiers can reduce the risk of duplicate work when a job is retried, redelivered, or resumed after a failure.

Retries should be limited and observable so persistent failures do not create uncontrolled loops, repeated customer messages, duplicate documents, or duplicate financial effects.

Failed jobs should be visible to appropriate operational personnel and should have safe recovery, retry, cancellation, or reconciliation procedures.

KOMERRA’s incident-response process is intended to support detection, triage, containment, investigation, remediation, recovery, communication, evidence preservation, and post-incident improvement.

Potential incidents may involve unauthorized access, credential exposure, tenant-isolation failure, malware, provider compromise, payment manipulation, data loss, service disruption, privacy breach, or another material security event.

Affected sessions, credentials, services, providers, integrations, routes, Accounts, or Workspaces may be temporarily restricted while a risk is assessed.

Relevant logs, audit events, provider references, request identifiers, deployment history, configuration changes, and affected records may be reviewed to determine scope and cause.

Incident communications should distinguish confirmed facts from preliminary findings and should avoid unnecessary exposure of security details or personal data.

Material incidents should lead to documented corrective actions, assigned ownership, target dates, testing, and follow-up review.

Where a personal-data incident affects information for which a business is the data controller and KOMERRA acts as processor, KOMERRA will provide notification and reasonable assistance according to the Data Processing Agreement and applicable law.

Where KOMERRA is the responsible data controller, it will assess the incident’s nature, scope, affected information, likely consequences, risk, containment, and applicable notification duties.

KOMERRA will notify affected people and the Nigeria Data Protection Commission or another competent authority where required by applicable law.

Notification timing and content depend on the circumstances, available information, risk, legal requirements, regulator direction, and whether communication would compromise an active security or law-enforcement investigation.

KOMERRA maintains incident records for accountability, investigation, improvement, legal compliance, and defense of rights.

KOMERRA welcomes good-faith reports of suspected vulnerabilities that may affect the confidentiality, integrity, availability, authentication, authorization, tenant isolation, payment integrity, or privacy of the Services.

Reports should be sent privately to support@komerra.app with “Security Report” in the subject.

A useful report should include the affected page or service, steps to reproduce, expected and observed behaviour, approximate time, potential impact, and safe supporting evidence.

Researchers and users must not access another person’s records, perform destructive testing, disrupt production, use social engineering, retain unnecessary personal data, demand payment through threats, or publish sensitive details before KOMERRA has had a reasonable opportunity to investigate and remediate.

Submitting a report does not automatically create an entitlement to payment, public recognition, employment, or participation in a bounty programme unless KOMERRA separately publishes such a programme.

KOMERRA should acknowledge, investigate, prioritize, and communicate about credible reports according to the risk and available evidence.

Security is shared between KOMERRA and the businesses and users operating Accounts and Workspaces.

KOMERRA is responsible for the platform controls within its scope. Businesses remain responsible for how they configure access, use customer information, approve actions, verify payments, protect devices, and operate their own business processes.

Businesses should identify which processes are critical and establish reasonable fallback procedures for periods when KOMERRA, a connected provider, the internet, a payment service, or another dependency is unavailable.

Fallback procedures may include alternative customer-contact methods, independent bank verification, local copies of essential contact information, manually issued records, order reconciliation, and procedures for restoring updates after service recovery.

A business should not depend exclusively on an AI feature, connected channel, or automated process for a legal deadline, emergency communication, irreversible financial decision, or other critical activity without a suitable alternative.

KOMERRA may assist with recovery and reconciliation but cannot guarantee that every third-party provider, network, device, or customer-controlled system will remain available.

KOMERRA does not claim that any internet-connected system is impossible to compromise.

KOMERRA does not claim that using encryption, hosting providers, row-level security, audit logs, or another individual safeguard eliminates all risk.

KOMERRA does not claim that a Trust Passport guarantees a business’s honesty, solvency, product quality, delivery, or future conduct.

KOMERRA does not claim that an AI confidence score is proof of accuracy.

KOMERRA does not claim that a payment screenshot or browser redirect proves final settlement.

KOMERRA does not claim ISO/IEC 27001 certification, a SOC 2 report, PCI DSS validation, regulatory approval, or another formal assurance status unless a current and appropriately scoped certificate, report, validation, registration, or official confirmation exists.

A provider’s certification does not automatically certify KOMERRA or a business using KOMERRA.

ISO/IEC 27001 specifies requirements for establishing, implementing, maintaining, and continually improving an information-security management system.

KOMERRA may use ISO/IEC 27001 principles as references for governance, risk assessment, policies, access management, supplier oversight, incident response, continuity, internal review, corrective action, and continual improvement.

Alignment with selected requirements or controls is not the same as certification.

KOMERRA should describe itself as ISO/IEC 27001 certified only where an accredited or otherwise appropriate certification process has been completed, the certificate remains valid, and the published statement accurately reflects the certified organization, locations, services, and scope.

When certification is completed, the certificate date, scope, certification body, validity period, and applicable exclusions should be published or made available through an appropriate assurance process.

SOC 2 is an independent examination of controls at a service organization using applicable Trust Services Criteria.

The Trust Services Criteria include security and may also include availability, processing integrity, confidentiality, and privacy depending on the examination’s scope.

KOMERRA may use the criteria as references for designing, documenting, operating, and evaluating controls.

Control alignment, readiness work, internal assessment, or use of a SOC 2-ready platform does not mean that KOMERRA has completed a SOC 2 examination.

KOMERRA should state that it has a SOC 2 report only after an independent practitioner has completed the examination and issued the report.

Where a report exists, access may be limited to eligible customers, prospective enterprise customers, auditors, or advisers under confidentiality because SOC 2 reports may contain sensitive system and control information.

PCI DSS provides baseline technical and operational requirements designed to protect payment account data in environments where that information is stored, processed, or transmitted.

KOMERRA’s preferred approach is to minimize direct handling of payment-card account data and use payment-provider interfaces designed to keep sensitive credentials within the provider’s payment environment.

Using a PCI DSS-compliant payment provider does not automatically establish KOMERRA’s own PCI DSS compliance or remove every responsibility applicable to the merchant, integration, or surrounding environment.

KOMERRA should publish a PCI DSS compliance or validation claim only after its actual payment data flows and applicable scope have been assessed and the required evidence remains current.

Businesses accepting payment through their own providers remain responsible for understanding and satisfying the payment-security responsibilities applicable to their own payment methods, devices, integrations, and Accounts.

As KOMERRA’s assurance programme matures, available evidence may include security policies, architecture summaries, control matrices, provider information, penetration-test summaries, vulnerability-management information, incident procedures, privacy documentation, continuity information, independent reports, certificates, or completed customer questionnaires.

Not all assurance material can be published publicly because detailed infrastructure, control configuration, vulnerabilities, test findings, credentials, or internal procedures could create security risk.

Access to non-public assurance material may require identity verification, a legitimate business purpose, an active procurement or customer relationship, and an appropriate confidentiality agreement.

KOMERRA may provide summaries, redacted material, provider reports, or written responses where the full underlying document cannot reasonably be shared.

The availability of evidence depends on the request, sensitivity, legal restrictions, provider permissions, assurance stage, and the requesting party’s relationship with KOMERRA.

KOMERRA may commission independent penetration testing, architecture assessment, privacy review, compliance readiness work, or other specialist evaluation as the platform and risk profile mature.

A test should have a defined scope, date, methodology, environment, exclusions, and remediation process.

A penetration test does not prove that a system is permanently secure. Findings represent the tested scope and conditions at a particular time.

Material findings should be prioritized, assigned, remediated, retested where appropriate, and tracked to closure or a documented risk decision.

KOMERRA should not describe a test as completed or passed unless the engagement occurred and the statement accurately reflects its scope and results.

Public summaries may omit technical details that would materially increase security risk.

A KOMERRA Trust Passport may present business information, completed checks, verification indicators, policies, platform activity, or other trust signals.

A Trust Passport does not constitute a government certification, credit rating, insurance guarantee, professional licence, guarantee of delivery, guarantee of product quality, promise of future conduct, or endorsement by KOMERRA.

Verification indicates only that specified information or checks were completed or reviewed at a particular time.

Trust Passport information may become outdated, disputed, revoked, or subject to re-verification.

Customers should continue to assess the business, transaction terms, payment details, product information, delivery arrangements, return policy, and other material risks.

The KOMERRA Service Status page is intended to provide information about current or recent platform availability, material incidents, scheduled maintenance, degraded services, and resolved disruptions where appropriate.

Status information may be preliminary while an incident is being investigated and may be updated as new evidence becomes available.

A service-wide status page may not reflect a problem affecting only one Account, Workspace, device, provider configuration, location, or integration.

Users should include the approximate time, affected feature, provider, error message, and available request identifier when reporting an issue.

KOMERRA should publish incident information that is useful and accurate without exposing credentials, personal data, exploitable technical details, or confidential provider information.

KOMERRA may update this Trust Centre when controls, architecture, providers, services, risks, regulatory requirements, assurance status, or operating practices change.

Material changes to public assurance claims should be reflected accurately and without unreasonable delay.

A control that is removed, materially changed, no longer verified, or restricted to a narrower scope should not continue to be described as universally implemented.

Historical versions or relevant change records may be retained for accountability and customer review where appropriate.

The Trust Centre does not replace a signed enterprise agreement, Data Processing Agreement, service-level agreement, or independently issued assurance report.

Questions about KOMERRA’s security architecture, privacy programme, responsible-AI controls, payment integrity, providers, data governance, reliability, incident response, or assurance posture may be sent to support@komerra.app.

Use the subject “Trust and Assurance Request” for enterprise security reviews, procurement questionnaires, control evidence, or audit-related enquiries.

Use the subject “Security Report” for a suspected vulnerability or security weakness.

Use the subject “Privacy Request” for access, correction, deletion, objection, portability, consent withdrawal, or another personal-data request.

Please include the relevant Account, Workspace, feature, business relationship, deadline, and requested information. Do not send passwords, card security codes, private keys, recovery codes, or unnecessary identity documents through ordinary email.