Skip to content

Security practices

Employee Security

How WebCastle manages security across the employment lifecycle — confidentiality obligations, account provisioning, device practices, offboarding and awareness.

10 of 12 controls operating todayDomainIn practiceReviewed 12 August 2026

At a glance

  • Employment contracts include written confidentiality obligations.
  • Accounts are company-managed and provisioned by the technical team.
  • MFA is enforced on cloud consoles and critical administrative services.
  • A structured awareness program is in development.

Overview

Most security outcomes at a development company are decided by people. Engineers, designers and project managers hold the accounts that reach source code, build pipelines and hosting consoles, so the strength of WebCastle security depends on how those people are given access, what they are expected to do with it, and how quickly that access is withdrawn when it is no longer needed.

WebCastle handles this today through a small number of controls that are consistently applied: confidentiality obligations written into employment contracts, company-managed accounts on business systems, multi-factor authentication on administrative services, and access that is provisioned by the technical team when someone joins a project and removed when they leave the company. These are operational practices rather than documented procedures, and they are applied directly by technical leadership rather than by a dedicated security function.

The areas still being built are the ones that turn practice into evidence: a written employee security policy, an acceptable use standard, a recorded onboarding briefing, an offboarding checklist that produces an auditable record, and a structured awareness program with tracked completion. This page states which is which, so a customer security reviewer can see exactly where WebCastle stands rather than inferring it.

Employee security controls

Each control below carries an honest maturity status. Controls marked in progress, developing or under evaluation are not yet something a customer should rely on contractually.

Confidentiality and non-disclosure obligations

Established

Employment contracts include written confidentiality obligations covering WebCastle information and customer information handled during an engagement. These obligations continue after employment ends.

  • Confidentiality covers customer source code, credentials, project documentation and any personal data encountered during delivery.
  • Where a customer requires a project-specific or company-to-company NDA, WebCastle signs it in addition to the standard employment terms.
  • Contract staff and interns are engaged under terms that include equivalent confidentiality wording.

Company-managed accounts

Established

Business systems are accessed through accounts that WebCastle owns and administers — email, source control and cloud consoles. Personal accounts are not used for company or customer work.

  • Accounts are issued individually. Shared logins are avoided for systems that support named users.
  • Because accounts are company-owned, they can be suspended centrally without depending on the individual.

Multi-factor authentication

Established

Multi-factor authentication is enforced on cloud provider consoles and critical administrative services. Staff with access to those systems must complete a second factor at sign-in.

  • Applies to cloud infrastructure consoles and the administrative interfaces used to manage hosting and deployments.
  • Extension of MFA enforcement to every remaining business application is tracked as part of the access control program.

Access provisioning and removal

Established

Access is provisioned by the technical team when someone is assigned to a project, and removed when they leave the company. Requests go through technical leadership rather than being granted peer to peer.

  • Project access is scoped to the systems needed for that engagement rather than granted company-wide by default.
  • Departure triggers removal of email, source control and hosting access.
  • Recording provisioning and removal as a dated, reviewable log is in progress and covered separately below.

Employee security policy

Operating

A written employee security policy is being drafted. It will consolidate the expectations that are currently communicated verbally by technical leads into a single reviewed document.

  • Scope will cover account handling, credential storage, device use, customer data handling and incident reporting.
  • Until the policy is approved, expectations are set during project onboarding by the technical lead.

Acceptable use standard

Operating

Acceptable use rules for company systems, networks and customer environments are being written up. No approved acceptable use policy exists yet.

  • Drafting covers permitted use of company accounts, restrictions on moving customer data to personal storage, and use of third-party and AI services in delivery work.
  • The standard will be published to staff and summarised on this page once approved.

Offboarding checklist

Operating

Access removal happens on departure today, but it is carried out from working knowledge rather than from a documented checklist. A written checklist with a recorded sign-off is being introduced.

  • The checklist will cover account suspension, source control and cloud console removal, credential rotation for any shared secrets, and return of company equipment.
  • Completion records are intended to give customers evidence that access was withdrawn, not just an assurance that it was.

Security awareness

In practice

Security awareness is currently handled through direct guidance from technical leads during project work — how to handle customer credentials, what to do with suspicious email, and how to escalate. WebCastle is developing a structured awareness program with recorded completion.

  • Guidance today is delivered in context, at the point where a decision is being made, rather than as scheduled training.
  • The planned program will cover phishing and social engineering, credential handling, device basics and incident reporting.
  • Completion tracking and periodic refreshers are part of the design. Neither exists today.

Onboarding security briefing

In practice

New joiners receive account setup and practical guidance from their technical lead. A consistent security briefing with a fixed agenda and a record that it took place is being introduced.

  • Present-day onboarding reliably covers account creation, MFA enrolment and project access.
  • The formal briefing will add data handling expectations, reporting routes and confidentiality reinforcement.

Workstation and device practices

In practice

Staff are expected to keep operating systems and browsers updated, use screen locks, and avoid storing customer data outside approved systems. These expectations are communicated directly and are not centrally enforced.

  • Full-disk encryption is encouraged on devices used for delivery work but is not centrally enforced or verified.
  • Device baseline expectations are being written into the employee security policy so they can be stated and checked consistently.

Endpoint management and monitoring

Under Evaluation

Mobile device management and endpoint detection and response are being assessed. WebCastle does not operate MDM or EDR today, and makes no claim of centrally enforced device configuration.

  • Evaluation is focused on the devices that hold source code and production credentials rather than on the whole fleet at once.
  • Any adoption will be reflected here with a change of status, not in advance of it.

Pre-employment screening

Under Evaluation

Formal background checks are not part of WebCastle hiring today. Candidate assessment is based on interview, technical evaluation and prior work. A screening standard for roles with production access is being considered.

  • Where a customer requires screening for staff on their engagement, WebCastle will discuss it as a contractual requirement rather than assert an existing process.

The employment lifecycle

What happens to access and security expectations at each stage. Steps describe current practice, with gaps identified where they exist.

  1. Offer and contract

    Before day one

    The employment contract is signed, including written confidentiality obligations that cover WebCastle and customer information. Role and reporting line determine which systems the joiner will need.

  2. Account creation and onboarding

    First days

    The technical team creates company-managed accounts for email, source control and any tools the role requires, and enrols the joiner in multi-factor authentication where the service enforces it. The technical lead covers practical security expectations for the work.

  3. Project assignment

    Per engagement

    Access to a customer environment, repository or cloud account is granted at the point of assignment and scoped to that engagement. Customer-provided credentials are handled under the terms the customer sets.

  4. During employment

    Ongoing

    Security guidance is delivered by technical leads in the context of live work. Staff are expected to raise anything suspicious immediately rather than investigating it themselves.

  5. Role or project change

    As it happens

    Access follows the new assignment. Removal of access to a completed engagement is performed by the technical team; consistently recording that removal is part of the access review work in progress.

  6. Departure

    On leaving

    Company-managed accounts are suspended and source control and hosting access is removed. Equipment is returned. Confidentiality obligations survive the end of employment. A documented checklist with recorded sign-off is being introduced to make this evidenceable.

What WebCastle expects of its people

These expectations are communicated directly by technical leadership today and are being consolidated into the employee security policy.

  • Use company accounts for company work

    Customer code, documentation and data stay in WebCastle-managed or customer-provided systems. Personal email, personal cloud storage and personal repositories are not used for delivery work.

  • Protect credentials

    Credentials are not shared between individuals, posted in chat, or committed to source control. Where a shared secret is unavoidable, it is handled through the technical team and rotated when someone with knowledge of it leaves.

  • Complete the second factor

    Multi-factor authentication prompts are never approved unless the person triggered the sign-in themselves. Unexpected prompts are treated as a security event and reported.

  • Keep devices current

    Operating systems, browsers and development tooling are kept updated, and devices lock when unattended. Devices used for delivery work should have disk encryption enabled.

  • Handle customer data as the customer would

    Production data is not copied to local machines or into test environments where the engagement can be delivered without it. Sample or anonymised data is preferred for development and testing.

  • Report first, investigate second

    A suspected phishing email, a lost device, an accidental data exposure or an unexpected login is reported immediately. Reporting something that turns out to be harmless is always the correct decision.

Remote and hybrid working

WebCastle delivery work is performed from company offices and, for some roles and periods, remotely. The following describes how that is handled.

Where work happens
Delivery is primarily office-based, with remote working used for specific roles, projects and periods. Remote access uses the same company-managed accounts and multi-factor authentication as office-based access.
Networks
Staff working remotely are expected to use trusted networks and to avoid administrative work on open public Wi-Fi. Access to cloud consoles is protected by account credentials and MFA rather than by network location.
Physical security of devices
Devices are not left unattended in public spaces, and screens are locked when the user steps away. Loss or theft of a device used for delivery work is reported to technical leadership the same day so credentials can be rotated.
Customer-imposed conditions
Where a customer contract restricts work to specific locations, networks or customer-provided equipment, those terms take precedence over WebCastle default practice for that engagement.

How employees report security concerns

Anything that looks like a security problem is escalated to technical leadership immediately, and to the monitored security mailbox where a written record is useful. Staff are told to report on suspicion rather than on certainty: a phishing email that might be genuine, an MFA prompt that was not expected, a file shared with the wrong recipient, or a device that has gone missing.

Reports are triaged by technical leadership, who decide whether the event is an incident and whether a customer needs to be informed. The escalation path, severity definitions and customer notification expectations are documented on the incident response page.

WebCastle does not penalise staff for reporting a security concern that turns out to be a false alarm. Under-reporting is treated as the greater risk, and this position will be stated explicitly in the employee security policy once approved.

Related