Bounded customer surface
Customer access is explicit and fail-closed without its dedicated identity environment. Checkout, content upload and silent submission remain inactive.
SECURITY / RT-PUB-007EFFECTIVE · VERSION 1.3
SECURITY IS BUILT INTO THE OPERATING MODEL.
The public security position, project controls, incident handling and shared responsibility.
CURRENT IMPLEMENTATION FACTS
THE PUBLIC ATTACK SURFACE IS INTENTIONALLY NARROW.
Local draft forms
Contact and project forms create local email drafts and do not transmit to a hidden website endpoint.
No public file intake
Sensitive evidence is exchanged only after a channel and responsibility boundary are agreed.
Controlled publication states
Incomplete legal and policy routes remain clearly labelled and noindex.
Security headers and release checks
The repository defines fail-closed build checks, security headers and protected preview workflow.
No certification claim
Implementation facts are not converted into unsupported universal compliance or certification claims.
SECURITY PRINCIPLES FOR CLIENT WORK
SECURITY IS A PROJECT-SPECIFIC RESPONSIBILITY MODEL.
Purpose before access
Access exists only for a defined operating purpose and accountable owner.
Least privilege
People, agents and systems receive the minimum authority required for the accepted role.
Separation of environments
Development, preview, production and sensitive customer contexts remain deliberately separated.
Secrets outside source code
Credentials and private keys are kept outside tracked source and public interfaces.
Human authority for consequential actions
Material external actions can require explicit approval and traceable execution.
Traceable change
Material configuration, code, permission and release changes remain reviewable.
Fail closed
Missing evidence or failed validation blocks release instead of being silently ignored.
Recovery before release
Rollback, interruption, restoration and responsibility are defined before a system becomes operational.
PROJECT-SPECIFIC SECURITY DEFINITION
THE ARCHITECTURE IDENTIFIES DATA, ACCESS, ENVIRONMENTS, SIDE EFFECTS AND RECOVERY.
- 01
Data categories, sources, locations and retention.
- 02
User, administrator, agent and provider access.
- 03
Identity, authentication and authorisation boundaries.
- 04
External tools, connectors and side effects.
- 05
Secrets, credentials and environment separation.
- 06
Logging, monitoring, incident and evidence requirements.
- 07
Backup, recovery, rollback and continuity.
- 08
Customer, RELESONA and third-party responsibilities.
RESPONSIBLE REPORTING
No public vulnerability bounty or reward programme is currently active. Credible reports are triaged, investigated and coordinated through the published reporting policy.
SECURITY REPORTING
OPEN SECURITY EMAILREPORT THE ISSUE WITHOUT SENDING SECRETS OR DESTRUCTIVE PROOF.
Send a concise initial report through the public email. Identify the affected URL, environment, reproducible steps and observed impact. A secure follow-up channel may be arranged after triage.
CUSTOMER SECURITY REVIEW
A CLIENT SYSTEM RECEIVES ITS OWN THREAT, ACCESS, DATA AND RECOVERY DEFINITION.
The public website policy is supplemented by project-specific architecture, supplier review and contractual allocation of responsibility.