Security FAQ

WebCastle Media Pvt. Ltd. builds and operates web and mobile applications for its customers. Security is treated as part of how that work is delivered: restricted access to systems and source code, separated environments, peer review of code changes, and reliance on established cloud provider controls rather than self-built alternatives.

WebCastle is currently formalizing this into a documented security program. That means writing down practices that already operate day to day, assigning clear ownership, and aligning the resulting controls with recognised frameworks. The Trust Center states the maturity of each area openly, including the areas that are still developing, so reviewers can assess WebCastle on what is actually in place.

The Security Practices page sets out the program area by area, and the Compliance page carries the current position on frameworks and certifications.

Accountability for security sits with WebCastle senior management. Day-to-day responsibility is held by the technical leadership team, which owns cloud infrastructure, production access, and the engineering standards applied across customer projects.

WebCastle does not have a dedicated full-time security function. Security responsibilities are assigned to named technical staff alongside their delivery roles, and formalizing those assignments is part of the ongoing development of the security program. Security enquiries, including customer reviews and vulnerability reports, are received at security@webcastle.in.

WebCastle operates a consistent set of internal practices covering access, development, hosting and confidentiality. These practices are applied across engagements, but a formally approved and signed-off policy set is still being drafted. WebCastle does not represent that it holds a complete, management-approved policy suite today.

Confidentiality obligations are contractual rather than aspirational: they are included in employment contracts and in customer agreements. Where a customer requires a specific policy commitment for an engagement, WebCastle can address it in the contract.

The Documents page lists each document, its current state, and whether it is public, available on request, or still in development.

A suspected incident is escalated to WebCastle technical leadership, who assess the scope, identify the affected systems and customers, and take containment action — typically revoking credentials, isolating the affected environment, and restoring from cloud provider backups where required. Remediation is followed by a review of the root cause and the changes needed to prevent recurrence.

WebCastle does not operate a 24/7 security operations centre or continuous monitoring. Detection relies on cloud provider alerting, application and infrastructure logs, and reports from staff and customers. WebCastle is formalizing its incident response procedure, including written severity definitions and escalation timelines, as part of the ongoing development of its security program.

The Incident Response page describes the current process in full.

Yes. Where WebCastle identifies an incident affecting a customer environment or customer data, WebCastle will notify the customer contacts named in the engagement without undue delay, and will provide what is known at the time: the systems affected, the data categories involved, the containment steps taken, and the next update.

Specific notification deadlines are set by the individual customer agreement. Where a customer requires a defined notification window, that should be agreed in the contract or Data Processing Agreement rather than assumed from this page. WebCastle does not publish a contractual notification service level.

Security expectations are communicated to employees when they join and are reinforced through the development workflow — code review, restricted access, and direct supervision by technical leads. Employment contracts include confidentiality obligations covering customer data and source code.

WebCastle does not currently run a formal security awareness training program with a fixed curriculum and tracked completion records. Establishing structured, recorded training is part of the ongoing development of the security program. The Employee Security page reflects the current position.

Each page carries the date its content was last reviewed, and each control carries a maturity status rather than a simple pass mark. Content is reviewed when a practice changes, when a new subprocessor is introduced, and on a periodic basis alongside the wider security program work.

The Trust Center is written to describe what WebCastle does today, not what is planned. Where an area is still developing, the page says so. If anything here appears out of date or inconsistent with what a customer has been told directly, contact security@webcastle.in and it will be corrected.

Customer data is protected by a combination of transport encryption, cloud provider managed encryption at rest, restricted access, and environment separation. Data in transit across WebCastle-managed services is protected with TLS. Storage and database services use the cloud provider managed encryption available to them. Access to production systems holding customer data is limited to a small number of technical personnel who need it for the engagement.

WebCastle prefers to work with the minimum data required. Where a customer environment can be developed and tested without production data, WebCastle uses non-production or masked data instead. Where production data is unavoidable, it stays inside the customer environment rather than being copied to developer machines.

The Data Protection page covers handling, encryption, retention and deletion in detail.

AWS is a primary cloud infrastructure provider for WebCastle-managed environments. The hosting region depends on the engagement and is agreed with the customer at the start of the project. WebCastle does not operate its own data centres.

Many WebCastle customers host their own applications in their own cloud accounts, with WebCastle building and operating the environment on their behalf. In those engagements the customer controls the hosting location and the underlying account, and WebCastle works within it. Where WebCastle hosts on the customer's behalf, the account, region and services in use are documented for the engagement.

The Infrastructure page describes the hosting model, and the Subprocessors page lists the third parties that may process customer data.

Yes, in most cases. Cloud regions are selected per engagement, so a customer with a residency requirement — for example that data must remain in the EU, the UK, India or the UAE — should raise it during scoping so the environment is provisioned in a matching region from the outset.

Residency for the primary application and database is straightforward to honour. Supporting services such as email delivery, error reporting or analytics may process limited operational data elsewhere, so any strict residency requirement should be checked against the specific services in scope. The Subprocessors page lists each provider and its processing region, and residency commitments should be recorded in the customer agreement.

Yes. Data in transit across WebCastle-managed services is protected with TLS, and public endpoints are served over HTTPS. Data at rest in storage and database services is protected using the cloud provider managed encryption available for those services.

WebCastle relies on the encryption implementations and key management provided by the cloud platform rather than building its own. Customer-managed keys can be discussed where a customer requires them and the platform in use supports it. Application-level or field-level encryption is implemented where a project specifies it.

The Data Protection page sets out how encryption is applied across the environments WebCastle manages.

Customer projects and data are logically separated from one another. Each engagement has its own application environment, its own database, and its own credentials. WebCastle does not run a shared multi-tenant platform in which several customers write into one database.

Separation extends to source code and access: repositories are per project, and access is granted only to the team members assigned to that engagement. A developer working on one customer project does not, by default, hold access to another. The Access Control page describes how this is enforced.

Backups use the native capabilities of the managed database and storage services in the environment — automated managed database backups and point-in-time recovery features where the platform provides them. Backups inherit the cloud provider managed encryption applied to the underlying service and are held within the same account and region as the environment unless a customer specifies otherwise.

Backup frequency and retention are configured per engagement rather than to a single published standard, and WebCastle does not publish a universal figure for either. Where a customer has a specific backup or retention requirement, it should be agreed for the engagement so the environment can be configured to match. The Business Continuity page describes the current approach.

WebCastle can restore a managed environment from cloud provider backups and rebuild application infrastructure from source-controlled code and configuration. In practice this is the recovery path for data loss, environment corruption or a failed deployment.

WebCastle does not currently hold a documented and regularly tested disaster recovery plan, and does not publish recovery time or recovery point objectives. Producing a written, exercised recovery procedure is part of the ongoing development of the security program. Where a customer requires committed recovery objectives, they should be agreed for the engagement and the environment architected to support them. The Business Continuity page states the current position.

At the end of an engagement WebCastle hands over the application, source code and any customer data held in WebCastle-managed environments, in a format agreed with the customer. Where the environment sits in the customer's own cloud account, WebCastle access is removed and the customer retains everything in place.

Following handover and on customer instruction, WebCastle removes customer data from environments it controls and revokes the team access associated with the engagement. Residual copies may persist in cloud provider backups until those backups age out under the retention configured for the service. WebCastle does not offer certified or attested secure data destruction.

Specific deletion and return obligations are governed by the customer agreement. The Data Protection page describes retention and deletion in more detail.

Yes. Multi-factor authentication is enforced on cloud provider consoles and on critical administrative services used to manage customer environments. This covers the accounts capable of changing infrastructure or reaching production data.

MFA coverage across every internal business application is still being extended, and WebCastle does not claim universal enforcement on all third-party tools today. Where a customer requires MFA on a specific system in scope for their engagement, WebCastle can confirm the position for that system. The Access Control page sets out where MFA is enforced.

Access is granted on the basis of role and project assignment. Team members receive access to the repositories, environments and services required for the engagement they are working on, and not to others. Production access is limited to a small number of technical personnel; most developers work against development and staging environments only.

Cloud access is managed through the provider identity and access management services, using individual named accounts rather than shared logins for administrative activity, with MFA enforced on the console. Source code is held in Git with repository access restricted to assigned team members.

Access requests and changes are approved by technical leadership. Formal written access-management procedures with recorded approvals are being developed as part of the wider security program. The Access Control page describes the current model.

When someone leaves WebCastle, technical leadership revokes their accounts and access: email and internal accounts, cloud provider access, source code repositories, and any customer environment credentials issued to them. Shared credentials that the individual held are rotated. Company equipment is returned.

Confidentiality obligations in the employment contract survive the end of employment and continue to cover customer data and source code. Offboarding is currently run as a coordinated manual process by technical leadership rather than an automated identity workflow, and formalizing it into a documented, recorded checklist is part of the ongoing development of the security program. The Employee Security page reflects this.

Application secrets and API keys are held in environment configuration and in the secret storage provided by the cloud platform or deployment pipeline, not committed to source control. Code review is used in part to catch credentials that would otherwise be checked in. Production credentials are known to the small group with production access, and are rotated when a team member with access leaves or when a credential is suspected to be exposed.

WebCastle is standardising secret management across projects and does not claim automated secret scanning across every repository. Where a customer requires a specific secret management approach for their environment, it can be adopted for that engagement.

Access is reviewed at the points where it matters most: when a team member joins or leaves a project, when someone leaves the company, and when an engagement ends. At those points access that is no longer required is removed.

Scheduled periodic access reviews across all systems, with recorded outcomes, are not yet operating as a formal cycle. Establishing a recurring, documented review is part of the ongoing development of the security program. The Access Control page states the current maturity of this control.

Security is handled inside the normal development workflow. Changes are made in version control, reviewed by another engineer before merge, and promoted through separate development, staging and production environments. Common web application risks — injection, broken authentication and authorisation, insecure direct object references, cross-site scripting — are addressed through framework features, parameterised database access, server-side validation and access checks enforced in application code.

Engineers work to the security guidance of the frameworks in use and to widely recognised web application security guidance such as the OWASP Top 10. WebCastle does not currently operate automated static or dynamic application security testing as an established capability across all projects; introducing tooling of that kind is part of the ongoing development of the security program.

The Application Security page describes the development lifecycle in full.

Yes. Peer review is a routine part of the development workflow. Changes are raised for review and merged after another engineer has reviewed them, with senior engineers and technical leads reviewing changes that touch authentication, authorisation, payment flows, or data handling.

Review covers correctness and maintainability alongside security-relevant concerns such as input validation, access checks and hardcoded credentials. Review is carried out by engineers rather than by a separate security team, and a formal security-specific review checklist is being developed.

Yes. Separate development, staging and production environments are maintained, with their own configuration and their own credentials. Changes are validated in development and staging before being promoted to production, and deployments to production are performed by the limited group holding production access.

Production data is not routinely copied into development or staging. Where realistic test data is needed, WebCastle uses generated, subset or masked data. This separation also limits the blast radius of a mistake: a developer working in staging cannot affect live customer data.

Applications are built on maintained frameworks and libraries, and dependency versions are pinned in source control so the composition of a release is known. Dependencies and platform components are updated during active development and maintenance work, and a security advisory affecting a component in use is assessed and patched based on its severity and exposure.

For managed services, patching of the underlying platform is handled by the cloud provider. For application dependencies, WebCastle does not currently run automated vulnerability scanning across every repository as an established capability, and does not publish a fixed patching service level. Where an engagement includes an ongoing maintenance agreement, update cadence is defined in that agreement.

WebCastle does not currently commission formal third-party penetration testing of its own systems, and holds no penetration test report to share. Security assurance today comes from peer code review, secure development practice, restricted access, and reliance on cloud provider platform controls.

Customers frequently arrange their own penetration testing of applications WebCastle has built, and WebCastle supports that: it will coordinate on scope and timing, provide the environment access the tester needs, and remediate findings. Engaging independent testing is under evaluation as the security program develops. The Application Security page carries the current position.

APIs are served over HTTPS and require authentication. Depending on the project, that is token-based authentication, OAuth, or platform-native authentication provided by the hosting environment. Authorisation is enforced server-side on every request rather than relying on the client, and input is validated at the API boundary.

Additional controls are applied according to the risk of the interface: rate limiting on public endpoints, restricting internal APIs to known networks or services, and scoping credentials to the minimum permissions required. Secrets used by integrations are held in environment configuration, not in source control.

Managed environments generate application logs, server and platform logs, and cloud provider service logs. These are used for troubleshooting, for investigating errors, and for establishing what happened during an incident. Cloud provider audit logging records administrative activity in the account.

WebCastle does not operate a centralised SIEM, continuous log monitoring, or automated security alerting across all customer environments as an established capability. Log retention follows the configuration of the underlying services for each engagement. Improving logging, retention and alerting is part of the ongoing development of the security program, and the Infrastructure page states the current maturity.

No. WebCastle does not currently hold ISO/IEC 27001 certification and has not been audited against the standard by a certification body. Any statement to the contrary would be inaccurate.

WebCastle is formalizing its security program and using recognised frameworks, including ISO/IEC 27001, as a reference for structuring its controls, documentation and ownership. Mapping controls against a framework is not the same as certification, and WebCastle does not present it as such. Whether to pursue formal certification is under evaluation and depends on customer demand and the maturity of the underlying program.

The Compliance page carries the current position on every framework WebCastle is asked about.

No. WebCastle has not undergone a SOC 2 Type I or Type II examination and has no SOC 2 report to provide. There is no auditor attestation covering WebCastle systems.

For customers who need assurance today, WebCastle can complete a security questionnaire, describe its controls in detail, provide the information published across this Trust Center, and enter into contractual security commitments. Where a customer requires an independent report, WebCastle will say so plainly rather than offer a substitute presented as equivalent. The Compliance page is kept current on this.

GDPR is a regulation, not a certification: no body issues a GDPR certificate, so no organisation can produce one. WebCastle therefore does not claim a blanket "GDPR compliant" status, and treats compliance as something demonstrated through specific practices and contractual commitments rather than asserted as a badge.

Where WebCastle processes personal data on behalf of a customer, it acts as a processor and works on the customer's instructions. In that role WebCastle limits access to personal data to the team members who need it, applies TLS in transit and cloud provider managed encryption at rest, keeps customer environments logically separated, supports the hosting region agreed for the engagement, will sign a Data Processing Agreement, and will assist the customer in responding to data subject requests and in investigating incidents affecting personal data.

The precise obligations that apply — including notification timeframes, subprocessor consent, deletion and audit rights — are governed by the individual customer agreement and Data Processing Agreement. The WebCastle privacy policy describes how personal data is handled more generally, and the Privacy page on this Trust Center summarises the position.

WebCastle does not hold a PCI DSS certification or Attestation of Compliance. Where WebCastle builds applications that take payments, it integrates PCI-compliant third-party payment gateways so that card data is captured and processed by the gateway rather than stored in the application WebCastle operates.

That design reduces the cardholder data environment but does not remove the customer's own PCI obligations, which remain with the merchant. Customers with a PCI scope requirement should raise it during scoping so the integration approach can be confirmed for the engagement.

Yes. WebCastle relies on established third-party providers to deliver its services — cloud infrastructure such as AWS, source code hosting, communication and collaboration tools, and, depending on the engagement, services such as email delivery, error reporting or analytics. Some of these may process customer data on WebCastle's behalf.

The Subprocessors page lists each provider, the service it delivers, the purpose, the data involved and the processing region. Customers with engagement-specific constraints — for example a residency requirement or a restriction on a particular provider — should raise them during scoping, and the arrangement can be recorded in the customer agreement or Data Processing Agreement.

WebCastle favours established providers with a published security posture, a track record of operating at scale, and terms that support the confidentiality obligations WebCastle owes its customers. New providers that would handle customer data are assessed by technical leadership before adoption, considering what data the provider would receive, where it would be processed, and what its own security documentation states.

A formal, documented vendor risk assessment process with recorded reviews on a defined cycle is being developed as part of the wider security program. The Vendor Security page describes the current approach, and the Subprocessors page lists the providers in use.

Yes. WebCastle completes customer security questionnaires, vendor assessments and due-diligence forms in whatever format the customer uses — spreadsheet, portal, or a standard framework such as CAIQ or a SIG-style questionnaire. Send it to security@webcastle.in with the deadline and the intended reviewer, and it will be routed to the technical leadership team.

Answers are given conservatively and match what is published here. Where a control is not yet in place, the questionnaire will say so rather than overstate the position. If a questionnaire assumes certifications WebCastle does not hold, the response will state that plainly and describe the compensating practices.

Yes. WebCastle signs non-disclosure agreements, and will do so before a security review or technical discussion where the customer requires it. WebCastle also enters into Data Processing Agreements where it processes personal data on a customer's behalf, including terms covering the purpose of processing, confidentiality, subprocessors, security measures, assistance with data subject requests, and return or deletion of data at the end of the engagement.

WebCastle can work from the customer's own paper. Send the agreement to security@webcastle.in, or raise it with the commercial contact for the engagement, and it will be reviewed. Security and data protection commitments made in a signed agreement take precedence over the general descriptions published on this Trust Center.

Email security@webcastle.in with the documents you need and the context — the engagement or proposal it relates to, and the deadline you are working to. WebCastle aims to acknowledge document requests within five business days.

The Documents page lists what is available and how each item is classified: public documents can be downloaded directly, on-request documents are shared with customers and prospects under NDA where appropriate, and items still in development are labelled as such. WebCastle does not hold certification reports or audit attestations, so those cannot be provided; where a request is for something that does not exist, WebCastle will say so and offer the closest equivalent, such as a completed questionnaire or a written control description.

Email security@webcastle.in with enough detail to reproduce the issue: the affected system or URL, the steps taken, and the impact you observed. Include a way to contact you for follow-up. WebCastle aims to acknowledge reports within two business days and to complete initial triage within five business days.

WebCastle asks researchers to avoid accessing, modifying or deleting data belonging to others, to avoid degrading service availability, and to give WebCastle reasonable time to remediate before disclosing publicly. WebCastle does not currently operate a paid bug bounty program, but genuine reports are welcomed and credited where the reporter wishes.

The Vulnerability Disclosure page sets out the full reporting guidelines and scope.

Ownership of custom-developed source code is set by the customer agreement. In WebCastle standard engagement terms, the customer owns the custom application code developed for them, subject to any third-party or open-source components used within it and to the terms of the specific contract.

Source code is held in Git, with repository access restricted to the team members assigned to that engagement. Code from one customer engagement is not accessible to teams working on another. At the end of an engagement the repository and its history are handed over, or WebCastle access is removed where the repository already sits in the customer's own organisation.