Security practices
Vendor Security
How WebCastle selects, reviews and oversees the third-party services it depends on, including the subprocessors that may handle customer data.
At a glance
- Vendors and cloud services are selected by technical leadership.
- AWS is the primary cloud infrastructure provider.
- Subprocessors that may handle customer data are published.
- A documented vendor review process is being built.
Overview
WebCastle builds and operates software using third-party infrastructure and tooling. Cloud hosting, source control, communication and delivery tools all sit behind the work, and some of them can process customer data. A customer assessing WebCastle is therefore also assessing the small number of providers WebCastle depends on.
Two things are true of that supply chain today. First, it is deliberately narrow: infrastructure is concentrated with a primary cloud provider rather than spread across many, and new services are adopted through technical leadership rather than by individual teams signing up on their own. Second, the process around it is informal. Selection decisions are made on the basis of the provider published security posture, its market position and the needs of the engagement, but they are not recorded against a defined set of criteria or re-examined on a schedule.
This page describes the practice as it exists, names the parts that are still being formalised, and points to the subprocessor list — which is the authoritative record of which third parties may handle customer data.
How WebCastle uses third parties
Third-party services fall into three groups. Infrastructure providers host applications that WebCastle builds and, in some engagements, operates. Delivery tooling — source control, issue tracking, communication — supports the work and can incidentally hold customer information such as configuration details or screenshots. Business systems support WebCastle as a company and generally hold no customer data at all.
The distinction matters because it drives how much scrutiny a service receives. Infrastructure providers and any service that stores customer data are treated as subprocessors and are listed publicly. Tools that only ever hold WebCastle internal information are managed as ordinary business purchases.
Where a customer provides their own environment — their cloud account, their repository, their tooling — WebCastle works inside it under the customer terms. In those engagements the customer, not WebCastle, holds the vendor relationship, and WebCastle contributes named accounts and access hygiene rather than vendor governance.
Vendor categories and data exposure
How WebCastle classifies the services it depends on, and what that means for scrutiny.
| Category | Typical purpose | Customer data exposure |
|---|---|---|
| Cloud infrastructure | Hosting, compute, storage and managed databases for delivered applications | Direct — treated as a subprocessor and published |
| Source control and build tooling | Version control, code review and deployment pipelines | Application source code and configuration; credentials are held separately |
| Communication and collaboration | Email, messaging and document handling for delivery work | Incidental — project correspondence and shared documents |
| Monitoring and operational tooling | Availability checks, logging and error reporting for hosted applications | Operational and log data; scope depends on the engagement |
| Business systems | Internal company operations unrelated to delivery | None expected |
Exposure describes what a category can technically reach, not what every engagement actually uses. Per-engagement scope is confirmed in writing during contracting.
Vendor security controls
The current state of each control, stated honestly. Controls marked developing or planned should not be relied on in a contractual assurance.
Vendor selection through technical leadership
EstablishedVendors and cloud services are selected by the technical leadership team. Individual engineers and project teams do not independently adopt services that will hold customer data.
- Selection considers the provider published security posture and certifications, its operating history, the hosting region and the needs of the engagement.
- Concentrating the decision keeps the supplier estate small and reviewable.
Primary cloud infrastructure provider
EstablishedAWS is WebCastle primary cloud infrastructure provider. Consolidating hosting with a single major provider reduces the number of parties with access to customer workloads and simplifies the security baseline.
- Customer-directed hosting on another provider is supported where the engagement requires it, under that customer arrangement.
- The shared responsibility model applies: the provider secures the underlying platform, WebCastle configures and operates what runs on it.
Company-managed vendor accounts with MFA
EstablishedVendor consoles are accessed through company-managed accounts, and multi-factor authentication is enforced on cloud provider consoles and critical administrative services.
- Named accounts mean vendor access can be withdrawn centrally when someone leaves the company.
- Root and owner-level credentials for cloud accounts are restricted to technical leadership.
Subprocessor inventory
OperatingWebCastle maintains and publishes a list of third parties that may process customer data. Keeping it accurate as the estate changes, and tying updates to a defined review point, is still being formalised.
- The published list records provider, service, purpose, data categories and processing region.
- Change notification arrangements for customers are being defined as part of the contracting process.
Data processing agreements
OperatingWebCastle is working through data processing terms with the providers that handle customer data. Signed data processing agreements are not yet in place with every subprocessor.
- Several major providers apply data processing terms by default as part of their standard agreement; these are being reviewed and recorded.
- Where a customer requires a specific flow-down term, it is handled contractually for that engagement.
Vendor access to WebCastle and customer systems
OperatingThird parties are not granted standing access to WebCastle systems or customer environments. Where a provider needs access for support, it is arranged for the specific task and withdrawn afterwards.
- Support access is granted with the narrowest scope that resolves the issue, and is approved by technical leadership.
- Customer environments are accessed by WebCastle personnel under the customer terms; onward access by a WebCastle supplier is not granted without the customer agreement.
- Recording these grants and their withdrawal in a consistent log is part of the access review work in progress.
Security review before adoption
In practiceBefore a service that will touch customer data is adopted, technical leadership reviews the provider published security documentation, compliance position and data handling terms. This review is informal and is not yet recorded against fixed criteria.
- Review currently focuses on hosting region, encryption in transit and at rest, authentication options, and whether the provider publishes independent assurance.
- A documented review record — criteria, findings and decision — is being introduced so adoption decisions can be evidenced later.
Ongoing vendor oversight
In practiceProvider status pages, security advisories and breach notifications are monitored informally by the technical team, and material issues are acted on. A scheduled re-review of each vendor is not yet in place.
- Provider-announced incidents are assessed for impact on WebCastle-hosted customer workloads and escalated through the incident response process where relevant.
- A periodic review cycle, tied to the subprocessor list, is being designed.
Vendor offboarding
In practiceWhen a service is retired, the technical team closes accounts, revokes keys and integrations, and arranges removal or export of data held there. The steps are applied from working knowledge rather than a documented procedure.
- Offboarding covers API keys and tokens, OAuth integrations into source control or cloud accounts, and any stored data.
- A written offboarding checklist with recorded completion is being introduced alongside the onboarding review record.
Documented vendor management policy
PlannedNo approved vendor management policy exists yet. A written policy defining categories, review depth, approval authority and review frequency is on the security roadmap.
- The policy will set out which classes of service require documented review and which can be adopted as ordinary business purchases.
Vendor security questionnaires
PlannedWebCastle does not currently issue security questionnaires to its suppliers. For major providers, published independent assurance reports and trust documentation are used instead.
- A lightweight questionnaire for smaller providers that hold customer data is planned as part of the vendor management policy.
Vendor risk register
PlannedA consolidated register recording each vendor, its data exposure, its assessed risk and its review date is planned. No such register is maintained today.
- The register is intended to be the internal counterpart to the public subprocessor list, holding assessment detail that is not published.
The vendor lifecycle
How a third-party service enters, operates within and leaves WebCastle estate.
Need identified
Before adoptionA delivery or operational need is raised with technical leadership, together with what data the service would touch. Needs that can be met by an existing provider are met that way, keeping the estate small.
Selection and review
Before adoptionTechnical leadership reviews candidate providers against hosting region, security documentation, published assurance, authentication options and data handling terms. This review is currently informal and is being formalised into a recorded decision.
Onboarding
At adoptionCompany-managed accounts are created, multi-factor authentication is enabled where the provider supports it, and access is restricted to the people who need it. Services that may process customer data are added to the subprocessor list.
Operation
OngoingProvider status and security advisories are monitored by the technical team. Account access is adjusted as project assignments change, and provider-side incidents are assessed for customer impact.
Re-evaluation
On changeA material change — a provider security incident, a change to its terms or region, or a change in how WebCastle uses it — prompts reassessment. Scheduled periodic re-review is being introduced rather than relying on change triggers alone.
Offboarding
On retirementAccounts are closed, API keys and integrations are revoked, data is exported or removed, and the subprocessor list is updated. Recording completion of these steps is part of the checklist work in progress.
What customers usually need to know
Direct answers to the vendor questions that appear most often in security reviews.
- Does WebCastle run a formal vendor risk assessment?
- Not yet. Vendor selection is made by technical leadership using published provider security information, and a documented assessment process with recorded criteria is being built. The current state is described control by control above.
- Are subprocessors disclosed?
- Yes. Third parties that may process customer data are published with purpose, data categories and region on the subprocessor page, which is maintained as the estate changes.
- Can a customer object to a subprocessor?
- Yes. Objections and any requirement for advance notice of new subprocessors are handled contractually for the engagement. Raise them through the security contact route and they will be addressed in the agreement.
- Do vendors have access to customer systems?
- No standing access is granted. Where a provider requires access for a specific support case, it is scoped to that task, approved by technical leadership and withdrawn on completion — and, for customer-owned environments, only with the customer agreement.