1. Scope
This Security overview applies company-wide. It covers our public website, every platform we operate (today Hublinkly, Clavix 360°, and Modeza), the systems and websites we deliver and host for clients, and the internal tooling our team uses to build and run those services. As we add new products or take on new client engagements, the same practices and principles apply by default.
2. Data encryption
We treat encryption as a baseline, not an upgrade.
- In transit: every public endpoint we operate is served over HTTPS using modern TLS. HTTP traffic is redirected to HTTPS, and we use HSTS where appropriate so browsers refuse downgrades on return visits.
- At rest: data stored in our managed databases, object storage, and backups is encrypted at rest using the encryption capabilities of the underlying provider. Encryption keys are managed by the provider in line with current industry standards.
- Internal traffic: service-to-service communication runs over encrypted channels wherever the provider exposes them.
3. Authentication and access control
We design every system to be safe by default for the accounts and people who use it.
- User authentication: passwords are never stored in plain text. They are hashed using strong, modern algorithms (e.g. bcrypt, Argon2, or the password store of a reputable identity provider).
- Session security: sessions are bound to secure, HTTP-only cookies and expire on a sensible schedule. Sensitive flows re-verify the user where appropriate.
- Role-based access (RBAC): where a platform has different kinds of users (administrators, members, customers), permissions are modelled by role, not by individual override.
- Least privilege internally: our team has only the access required to do their work. Production access is restricted to a small group, controlled by strong authentication, and logged for accountability.
- Secrets handling: API keys, database credentials, and tokens live in managed secret stores or platform environment variables — never in source control.
4. Infrastructure
We host our platforms on modern, reputable cloud infrastructure operated by established providers. Production environments are separated from development and staging environments. Where we operate multiple client systems, each client's production environment is logically isolated — separate databases or schemas, separate storage buckets, separate credentials — so that one client's data is not commingled with another's. Our underlying providers operate physical-security and platform-security programmes that are described in their own published documentation.
5. Backups and reliability
For services we host on your behalf, we operate routine backups and platform-level redundancy in line with recognised industry practice.
- managed database backups are performed on a regular schedule and retained for a period appropriate to the service tier;
- object storage is replicated by the provider for durability;
- application deployments are versioned so we can roll back quickly if a release behaves unexpectedly;
- restore procedures are exercised when we make significant infrastructure changes.
Specific backup frequency, retention windows, and recovery objectives may be tightened in individual client contracts. Our Service Level Agreement describes our availability targets.
6. Monitoring and threat protection
We monitor the platforms we operate and apply standard protections against common threats.
- Network and edge: upstream providers operate DDoS mitigation and edge filtering. We rely on those capabilities and configure application-layer controls on top.
- Rate limiting: authentication endpoints, public APIs, and contact forms are rate-limited to discourage brute-force, credential stuffing, and scraping.
- Security headers: responses include sensible security headers (Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, and similar) tuned per application.
- Logging and review: application and infrastructure events are logged for accountability and incident investigation, and reviewed when suspicious activity is detected or reported.
- Dependency hygiene: we monitor application dependencies for published vulnerabilities and apply security updates on a reasonable schedule, accelerated for critical issues.
7. Payments
Where a service we operate involves taking payments, those payments are processed by reputable third-party payment providers who specialise in this area and are audited against industry standards such as PCI-DSS. DCG does not store full payment-card numbers, CVV codes, or equivalent raw card data on its own systems. We may retain limited payment-reference data (for example, an authorised charge identifier, the last four digits of a card, or an invoice status) so we can reconcile transactions and handle support requests. Refunds and cancellations are handled in line with our Refund & Cancellation Policy.
8. Data privacy and compliance
We treat privacy and security as two sides of the same discipline. Personal data we process is handled in line with the principles of the EU General Data Protection Regulation (GDPR), the UK GDPR, and similar regimes — including transparency, purpose limitation, data minimisation, storage limitation, and accountability.
For the legal detail, see our Privacy Policy (how we handle personal data of website visitors, prospects, and clients) and our Data Processing & GDPR notice (roles, sub-processors, international transfers, and data-subject rights). Use of our services is also subject to our Acceptable Use Policy.
9. Vulnerability management and updates
We keep our applications, libraries, and platform images on supported, current versions. Security advisories from upstream maintainers are reviewed when published and addressed on a risk-based timeline — critical issues are prioritised over feature work. Where a fix requires a breaking change for clients, we coordinate the upgrade and communicate the change.
10. Responsible disclosure
If you believe you have found a security vulnerability in a DCG platform, a website we operate, or this site itself, please report it to us at info@dynamiccommercegroup.com. Helpful detail in your report includes:
- the affected URL, application, or endpoint;
- a description of the issue and, where possible, reproduction steps;
- the impact you understand or suspect;
- your contact details, so we can acknowledge and follow up.
We ask that researchers act in good faith — avoid degrading services for other users, do not access more data than is necessary to demonstrate the issue, and give us reasonable time to investigate and remediate before disclosing publicly. We will acknowledge legitimate reports promptly and keep you informed as we work through them.
11. Incident response
If we become aware of a security incident affecting data we hold, we investigate without undue delay, take reasonable steps to contain and remediate, and notify those affected where notification is required or appropriate. For personal data, our breach-notification commitments are set out in our Data Processing & GDPR notice.
12. Ongoing improvement and certifications
We treat security as a continuous discipline rather than a one-time stamp. We do not currently hold formal information-security certifications such as ISO 27001 or SOC 2 Type II. As DCG grows and the scope of our operations warrants it, we may pursue formal certifications where they fit the needs of our clients. In the meantime, we are transparent about what we do today (described above), we apply established industry practices throughout our work, and we welcome questions or independent review from clients during onboarding and at contract renewals.
13. Shared responsibility
Strong security is a shared responsibility. We ask clients and platform users to keep account credentials safe, use strong unique passwords (and multi-factor authentication where offered), keep contact details current so we can reach the right people during an incident, and report anything suspicious promptly. For client engagements where we host or operate a system, security commitments specific to that engagement are set out in the relevant contract.
14. Changes to this page
We may update this Security overview from time to time to reflect new tools, new providers, or evolving practices. The “Last updated” date at the top of this page reflects the most recent revision. Material changes will be communicated through reasonable means.
15. Governing law
This Security overview is governed by the laws of Georgia. Any disputes that cannot be resolved by good-faith negotiation will be submitted to the competent courts of Batumi, Georgia, unless your contract with DCG specifies a different forum.
16. Contact us
For security questions, to report a vulnerability, or to request more detail on any practice described above, write to info@dynamiccommercegroup.com or visit our contact page. Dynamic Commerce Group is registered as an Individual Entrepreneur in Georgia.