01 · Principles
A practical, risk-based approach
Security decisions should follow the system's real use, data sensitivity, users, integrations, and threat model. Velixon favors clear architecture, limited data collection, least-privilege access, maintained dependencies, and simple controls that teams can operate reliably.
Specific controls vary by project and are defined during architecture and delivery. This page describes our general approach; it is not a certification, audit report, warranty, or promise that every listed measure applies to every system.
02 · Public website
How this website is protected
velixon.net uses HTTPS to encrypt information in transit between supported browsers and the website. It is delivered through managed hosting infrastructure and uses form-spam protections. We intentionally limit the information requested through the public site.
Hosting, analytics, email, domain, and other third-party providers maintain their own infrastructure and security programs. Their systems remain outside Velixon's direct control.
Do not submit passwords, secret keys, payment-card data, government identifiers, production datasets, or vulnerability details through the public form.
03 · Engineering
Security in client systems
Based on a project's requirements and written scope, Velixon's engineering approach may include:
- Documenting data flows, trust boundaries, roles, permissions, and high-risk operations.
- Using established authentication, authorization, encryption, and secret-management capabilities from appropriate platforms.
- Validating inputs, handling errors safely, and limiting sensitive information in logs and client-side code.
- Reviewing dependencies, deployment settings, database access, and environment separation.
- Designing backups, recovery paths, monitoring, audit history, or incident procedures when the system requires them.
- Verifying key workflows before release and addressing identified issues according to severity and scope.
Client-specific requirements—including regulated data, formal compliance frameworks, penetration testing, uptime commitments, and response times—must be agreed in writing.
04 · Responsible disclosure
Report a suspected security issue
If you believe you found a security vulnerability affecting velixon.net or a Velixon-controlled system, email Velixon.web@gmail.com with the subject “Security Report.” Do not use the general website form for vulnerability details.
A useful report includes:
- The affected URL, product, feature, or endpoint.
- A clear description of the issue and its potential impact.
- Safe, repeatable steps and the date and time observed.
- Minimal evidence needed to demonstrate the issue, with sensitive information removed.
- A reliable way for us to contact you with questions.
Do not email credentials, private keys, personal information, or copied production data. Ask us for a safer transfer method if sensitive evidence is necessary.
05 · Boundaries
Good-faith testing guidelines
Protect people and systems while investigating. Do not:
- Access, modify, retain, or share another person's data.
- Use denial-of-service, high-volume automation, spam, malware, social engineering, or physical attacks.
- Disrupt service, damage data, create persistence, or move beyond the minimum proof needed.
- Test third-party systems, customer environments, or products that Velixon does not control.
- Publicly disclose an unresolved issue before allowing a reasonable opportunity to investigate and respond.
This page is not authorization to access systems or data, does not create a bug-bounty program, and does not promise payment. If you are unsure whether testing is permitted, contact us before proceeding.
06 · Response
What happens after a report
Velixon will review credible reports, request clarification when needed, attempt to validate the issue, and prioritize corrective work based on likely impact and exploitability. Where practical, we will keep the reporter informed and confirm when our review is complete.
Response and remediation times depend on severity, complexity, ownership, availability of affected providers, and contractual responsibilities. This process does not establish a guaranteed service level.
07 · Partnership
Security is a shared responsibility
Durable security depends on more than application code. Clients remain responsible for their users, devices, credentials, administrators, content, policies, vendor accounts, legal requirements, and ongoing operational decisions unless a written agreement assigns a responsibility differently.
Velixon works with clients to make ownership clear, identify material risks, and choose maintainable controls. Clients should promptly revoke unnecessary access, protect credentials, review administrator activity, and notify Velixon of relevant changes or suspected incidents.
08 · Limitations
No system is completely secure
Reasonable safeguards reduce risk but cannot eliminate it. Vulnerabilities may arise from new threats, third-party services, misconfiguration, user behavior, or changes made after delivery. No statement on this page guarantees that a website or system is invulnerable, continuously available, or compliant with a particular standard.
Questions about personal information are addressed in the Privacy Policy. Website-use limitations are addressed in the Terms of Use.