Security starts
with clear responsibilities.

01 / SCOPE & LIMITATIONS

An approach, not an assurance report

Web Cincture aims to consider security throughout product discovery, design, engineering and release. This page explains that approach and the boundaries around reporting concerns relating to our digital properties.

It is not a penetration-test report, certification, compliance attestation or guarantee that a website, application or infrastructure is free of vulnerabilities. It does not establish that every control described here is implemented in every product.

Project requirements, actual configurations and supporting evidence must be reviewed for the relevant system. Contractual commitments, support arrangements and service levels are defined separately; this page does not create or replace them.

02 / SECURITY PRINCIPLES

Start with the people,
data and decisions.

Understand the context

Identify intended users, sensitive information, important workflows and the consequences of misuse before selecting controls.

Keep authority explicit

Consider least privilege and role boundaries. Define who should be able to view, change, approve or export relevant information.

Make responsibilities visible

Identify who owns accounts, configuration, testing, deployment and ongoing operation rather than assuming those tasks are automatically covered.

Use evidence appropriate to the scope

Agree what is to be reviewed and tested. A design intention or a passing build alone is not evidence of production security.

03 / ENGINEERING CONSIDERATIONS

Define the controls
the system actually needs.

The following are areas to evaluate during a scoped engagement. They are not a checklist of controls already verified across our portfolio.

Access and permissions

Authentication needs, role and tenant boundaries, server-side authorisation, privileged access and appropriate access-removal processes.

Data and credentials

Data minimisation, appropriate storage and transport protections, secret handling, access to sensitive records and retention requirements.

APIs and integrations

Input validation, provider permissions, trust boundaries, failure handling and the information shared with connected services.

Code, dependencies and release

Review scope, dependency awareness, environment separation, configuration review and release checks appropriate to the system.

Operational readiness

Logging needs, sensitive-data redaction, backup and recovery requirements, alert ownership and incident escalation arrangements.

Whether these controls are included, how they are configured and how they are verified depends on the agreement and operating context. Monitoring, recovery testing or continuous support should not be assumed from a general capability description.

04 / SHARED RESPONSIBILITIES

Agree who does what
before and after release.

Security depends on software, infrastructure, providers and the people operating them. For a particular project, clarify:

• Accounts and access: ownership of repositories, hosting, domains, app-store accounts, provider credentials and privileged permissions.
• Data and configuration: responsibilities for lawful inputs, permissions, production settings and information shared with providers.
• Verification: the scope and evidence for code review, testing or any separately commissioned independent assessment.
• Ongoing operation: patching, backups, recovery checks, monitoring, escalation and any support windows agreed in writing.
• Changes and handover: how new integrations, configuration changes, access transfers and maintenance work are approved.

Our own products may have separate operating arrangements and product-specific documentation. A statement about one deployment should not be treated as evidence about all other deployments.

05 / REPORT A CONCERN

Share the minimum
needed to understand the issue.

If you believe you have identified a potential security issue relating to a Web Cincture digital property, email info@webcincture.com with the subject Security concern.

1. Identify the affected public URL or product and when you noticed the issue.
2. Summarise the suspected behaviour and its potential impact.
3. Provide minimal reproduction details from activity you are authorised to perform. Do not continue testing to obtain more evidence.
4. If needed, include a redacted screenshot that does not expose credentials, personal data or private records.

Do not send passwords, session cookies, access tokens, identity documents, private source code or customer datasets. If a report requires sensitive material, describe the need first and ask about an appropriate sharing method.

Please avoid public disclosure of exploitable details while a concern can be assessed and coordinated. This contact route does not promise a response or resolution deadline, a reward, or a particular outcome. It is not a 24/7 incident hotline.

For account-specific or service-availability issues, use the support arrangements for the relevant product or engagement. This page does not replace those channels.

06 / TESTING BOUNDARIES

A reporting route
is not testing permission.

This notice does not grant authorisation to test Web Cincture, client or third-party systems. Any proposed security testing requires prior, explicit authorisation from the relevant system owner, with an agreed scope and method.

• Do not bypass access controls, use another person’s account or attempt to obtain private records.
• Do not perform disruptive scanning, denial-of-service activity, social engineering or actions that change or destroy data.
• Do not download or retain sensitive information to prove an issue.
• Do not assume that a linked product, hosting provider or client system is included in an authorised scope.

If you unexpectedly encounter information that is not yours, stop the activity and report the location and context without copying or redistributing the data. No bug-bounty programme, payment promise or legal safe-harbour undertaking is established by this page.

07 / REFERENCES & UPDATES

Useful references.
No implied endorsement.

The OWASP Top 10 is a public reference for understanding important web-application security risks. Linking to it does not mean that our company or a product is certified by OWASP, or that a particular assessment has been completed.

Read our Privacy Policy for personal-information handling, Cookie Policy for website technologies and Terms of Use for website-use boundaries.

This information may be updated as our website and engineering approach evolve. The updated date identifies the page version, not the completion date of a security audit.