Security built into the architecture.

Security overview

Projectix builds software that connects to third-party platforms and processes business data. Security is therefore an architectural concern rather than a final checklist: authentication, authorisation, credential handling, data retention and failure behaviour are decided while a system is being designed.

Our engineering approach follows established security and secure-development practices. We do not hold or claim ISO 27001, SOC 2 or PCI certification. If a formal certification is a requirement for your procurement process, tell us and we will give you a direct answer about our current position rather than an implied one.

Application security

Applications are written in TypeScript under strict compiler settings, and input arriving from a browser, an API client or a third-party platform is validated against an explicit schema at the boundary before it reaches business logic.

• Server-side validation is authoritative; client-side checks exist only to give faster feedback.
• Output is encoded in context, and templating avoids raw HTML interpolation of user-supplied values.
• Authorisation is checked on the server for every request, not inferred from the interface.
• Form endpoints apply request-size limits, rate limiting and anti-automation measures.

Infrastructure security

We deploy to managed cloud platforms and use their security primitives rather than maintaining bespoke infrastructure where a managed equivalent exists. Development, staging and production environments are separated, with their own credentials and their own data.

• No production application state is stored on ephemeral server filesystems.
• Administrative access to hosting platforms is restricted and protected by multi-factor authentication.
• Infrastructure changes are made through configuration under version control wherever the platform allows.

Encryption

Traffic to our applications and to third-party APIs is served over TLS. Where the underlying managed platform provides encryption at rest for databases, object storage and backups, it is enabled.

We describe encryption in terms of what the platforms we use actually provide. We do not claim bespoke cryptographic implementations, and we avoid building our own where a reviewed platform primitive exists.

Access management

Access follows the principle of least privilege. People and services receive the narrowest set of permissions needed for their role, and access is reviewed when responsibilities change.

• Application access is role-based, with administrative actions separated from everyday use.
• Multi-factor authentication is required for administrative access to the platforms we operate on.
• Shared accounts are avoided; access is attributable to an individual or a named service.

API security

Integrations authenticate explicitly. Tokens are scoped to the minimum permissions required, and expiry and rotation are honoured where the provider supports them.

• Requests to third-party APIs stay within documented usage, including rate limits and retry guidance.
• Our own APIs authenticate every request, validate payloads and apply per-client limits.
• Error responses avoid disclosing internal implementation detail.

Secrets management

Credentials, API keys and tokens are held in managed environment configuration provided by the hosting platform. They are never committed to source control, embedded in client-side bundles or shared over unencrypted channels.

• Each environment has its own secrets; production credentials are not reused in development.
• Secrets are rotated when a person with access leaves a project or when exposure is suspected.

Logging and monitoring

Application and integration activity is logged in a structured, consistent shape so that failures, anomalies and unexpected behaviour can be investigated rather than guessed at.

• Logs are designed to avoid recording credentials or unnecessary personal data.
• Integration failures, authentication errors and rate-limit events are observable.
• Alerting is configured for conditions that require a human response.

Software dependencies

Dependencies are pinned, reviewed before adoption and updated as part of routine maintenance. We prefer a small dependency surface: every third-party package is code we are responsible for operating.

• Lockfiles are committed so builds are reproducible.
• Security advisories affecting dependencies in use are assessed and acted on.
• Unused dependencies are removed rather than left in place.

Data minimisation

We collect and retain the smallest amount of data a feature genuinely requires. Where a system can work with an identifier, an aggregate or a derived value instead of a full record, it does.

For marketplace integrations this is a deliberate design constraint: data is requested for the functionality being provided, and not collected speculatively. Our Data & API Usage page sets out how this applies to third-party APIs.

Incident management

If we become aware of a security incident affecting a system we operate, we investigate, contain and remediate, then assess what notification is appropriate and required.

• Containment and preservation of relevant logs take priority over immediate explanation.
• Affected parties are informed where there is a legal or contractual obligation, or where notification is warranted.
• Remediation includes addressing the cause, not only the symptom.

Responsible disclosure

If you believe you have found a security vulnerability in a Projectix website or application, we would like to hear from you. Please contact us at the Projectix contact form with enough detail to reproduce the issue.

• Please give us a reasonable opportunity to investigate and remediate before public disclosure.
• Please do not access, modify or delete data belonging to anyone else while testing.
• Please avoid denial-of-service testing, spam, social engineering or physical attacks.

We do not currently operate a paid bug bounty programme. We will acknowledge reports, keep you informed of progress and credit you if you would like us to.