Security Statement
The security practices, shared responsibilities, and incident principles used across Excelin Systems work.
This page is intended as a clear public statement for website visitors and clients. It should be read together with any signed agreement, proposal, statement of work, or policy schedule that applies to a specific engagement.
1. Security Approach
Excelin Systems treats security as part of system design, not as a final checklist. We aim to build practical controls into the way applications, portals, automations, infrastructure, and integrations are planned, developed, released, and maintained.
Security decisions depend on scope, budget, data sensitivity, client requirements, third-party providers, and operational risk. This statement describes the general approach we aim to follow. Specific controls for a client system should be confirmed in the relevant proposal, architecture notes, security schedule, or managed services agreement.
2. Access Control
We design systems around least-privilege access. Users should receive only the access needed for their role, and administrative features should be limited to authorised people. Where practical, we support role-based access, secure authentication, account invitations, password reset flows, session management, and audit history for sensitive actions.
Clients are responsible for approving who should have access to their systems, removing users who no longer require access, protecting credentials, and telling us promptly if they suspect compromise. Shared accounts are discouraged because they make security and accountability weaker.
3. Development And Release Practices
We aim to use version control, staged environments, review processes, structured deployment steps, and testing appropriate to the size and risk of the project. For systems that handle sensitive operations, we plan safer release paths, access reviews, backups, and rollback considerations.
We also pay attention to dependency management, secret handling, input validation, error handling, permission checks, and provider configuration. No development process can remove all risk, but disciplined engineering reduces preventable mistakes.
4. Data Protection
We use reasonable safeguards for personal information, client data, credentials, and operational records. These may include HTTPS, provider encryption features, access controls, restricted administrative permissions, backups, audit logs, and separation between production and non-production data where practical.
Clients should avoid sending production credentials, sensitive personal information, or regulated data through public forms, chat tools, or unsecured email unless a secure handling process has been agreed. Where test data is sufficient, it should be used instead of live personal information.
5. Monitoring, Backups, And Recovery
For business-critical systems, we recommend monitoring the workflows that matter, not only whether a server responds. This may include uptime checks, error logs, queue failures, email delivery, payment events, backup status, and integration health.
Backup and recovery responsibilities should be stated clearly for each engagement. Creating backups is not enough on its own; teams should understand recovery expectations, retention limits, restoration steps, and the time required to return a service to normal.
6. Incident Response
If we detect or are informed of a suspected security incident affecting a system we operate or support, we will take reasonable steps to assess, contain, investigate, and communicate about the incident according to the service context. Where personal information may be involved, privacy breach assessment may also be required.
Clients should notify us promptly of suspicious activity, lost devices, compromised accounts, unauthorised access, unusual system behavior, or provider alerts that may affect a shared project. Early notice improves containment and reduces harm.
7. Vulnerability Reporting
If you believe you have found a vulnerability in an Excelin website, portal, or system, please contact support@excelinweb.com with enough detail for us to understand and reproduce the issue. Do not exploit the issue, access data that is not yours, interrupt services, or publicly disclose the issue before we have had a reasonable opportunity to investigate.
We appreciate good-faith reports. We may not provide monetary rewards unless a formal bug bounty program is announced, but we will treat responsible reports seriously and aim to respond in a reasonable time.
8. Shared Responsibility
Security is shared between Excelin, clients, users, and third-party providers. We can design and operate controls, but clients must make appropriate business decisions about access, data classification, provider accounts, retention, user training, and policy requirements.
This statement is not a guarantee that systems are immune from attack, outage, human error, provider failure, or misuse. It is a transparent summary of the security principles we aim to apply and the shared responsibilities that help protect clients and users.
9. Reviews And Client-Specific Controls
Some projects need a deeper security review than others. Systems that process sensitive personal information, payments, confidential business records, regulated data, or high-value operational workflows may require additional architecture review, penetration testing, provider assessment, access review, logging, backup validation, or incident planning. These activities should be scoped explicitly so responsibilities and costs are clear.
We encourage clients to raise security, compliance, insurance, procurement, and sector-specific requirements early. Requirements discovered late can affect timelines, architecture, provider selection, data handling, and launch readiness. Early discussion helps us design controls into the system instead of trying to retrofit them under deadline pressure.
Reference Points
These public resources informed the structure of this page. They are not incorporated as contract terms unless a written agreement says so.