Security program
Security Practices
WebCastle's information security program — how security is governed and owned, how risk is managed, and how each practice area is progressing.
At a glance
- Security is owned by WebCastle technical leadership.
- Nine practice areas, each published with an honest maturity status.
- Core access and infrastructure controls operate today.
- Written policies and formal governance are being built.
Overview
WebCastle Media Pvt. Ltd. builds and operates web and mobile applications for its customers. Security is therefore not a single product feature but a property of how WebCastle runs its accounts, its infrastructure, its development process and its people. This page is the entry point to that program: what it consists of, who owns it, how it is being improved, and where each part of it currently stands.
The program is being actively formalised. A set of controls operates reliably today — company-managed accounts, multi-factor authentication on cloud consoles and critical administrative services, access granted by the technical team on project assignment and removed on departure, infrastructure concentrated with a primary cloud provider, and confidentiality obligations written into employment contracts. Around those controls, WebCastle is building the documentation, evidence and review cycles that let a customer verify them rather than take them on trust.
Every practice page states its position using the same maturity scale, and no page claims more than WebCastle can support. Where a control is informal, it is described as informal. Where a policy is in draft, it is described as in draft. That is deliberate: a Trust Center that overstates is worse than one that is candid, because it fails at exactly the moment a customer tries to verify it.
How WebCastle approaches security
Five principles that shape the decisions behind the program.
State the real position
Every control on this site carries a maturity status that reflects operational reality. WebCastle publishes gaps alongside strengths so that a customer security review reaches the right conclusion the first time.
Reduce the surface before adding controls
Fewer providers, fewer standing privileges and fewer copies of customer data remove risk more reliably than layering tooling over a large estate. Infrastructure is concentrated with a primary cloud provider for the same reason.
Build on the platform
WebCastle uses the security capabilities of its cloud and tooling providers — identity, encryption, logging, managed backups — rather than reimplementing them. The shared responsibility model defines where WebCastle obligations begin.
Make practice evidenceable
Much of what WebCastle does today works but leaves no record. The current phase of the program is about producing evidence — written procedures, access records, completed checklists — so controls can be demonstrated, not just described.
Meet the customer where their requirements are
Engagement-specific security obligations are agreed contractually. Where a customer requires controls beyond WebCastle standard practice, that is handled explicitly in the agreement rather than assumed.
Governance and ownership
Security responsibility sits with WebCastle technical leadership. The same group that decides infrastructure architecture, approves cloud and vendor adoption, and holds administrative credentials is accountable for the security program. There is no separate security department, and WebCastle does not present one.
That concentration has a practical advantage at WebCastle scale: decisions about access, hosting and third-party services are made by people with direct knowledge of the systems, and there is no ambiguity about who owns an outcome. It also has a known limitation — security work competes with delivery work for the same attention — which is why the improvement program below is sequenced rather than attempted all at once.
Project-level security responsibility sits with the technical lead for each engagement. They decide who is assigned access, how customer-provided credentials are handled, and when to escalate. Escalation goes to technical leadership, who determine whether an event is a security incident and whether a customer must be notified.
A formally appointed information security officer, a documented governance forum with recorded minutes, and management review of security performance are not yet part of how WebCastle operates. Establishing a defined owner and a regular review point is the first item in the program below.
Security program controls
The governance-level controls that sit above the individual practice areas. Domain-specific controls are documented on each practice page.
Named security ownership
EstablishedSecurity responsibility sits with WebCastle technical leadership, who hold administrative credentials, approve infrastructure and vendor decisions, and act as the escalation point for security events.
- Customers and researchers reach this group through the published security mailbox.
- Project-level responsibility is delegated to the engagement technical lead.
Company-managed accounts on business systems
EstablishedEmail, source control and cloud consoles are accessed through accounts WebCastle owns and administers, which makes access centrally revocable and keeps company and customer work off personal accounts.
Multi-factor authentication on administrative systems
EstablishedMulti-factor authentication is enforced on cloud provider consoles and critical administrative services. These are the accounts that can reach customer workloads, so they carry the strongest authentication requirement.
- Root and owner-level cloud credentials are restricted to technical leadership.
- Extending enforcement across every remaining business application is tracked under access control.
Controlled adoption of cloud services and vendors
EstablishedVendors and cloud services are selected by the technical leadership team rather than adopted independently by project teams. This keeps the supplier estate small and known.
- AWS is the primary cloud infrastructure provider for WebCastle-hosted workloads.
- Services that may process customer data are published on the subprocessor list.
Written information security policy set
OperatingWebCastle is drafting its core security policies. No formally approved and signed-off policy documents exist yet, so current expectations are set and enforced directly by technical leadership.
- The first tranche covers information security, acceptable use, access control and vendor management.
- Each policy will carry an owner, a version and an effective date once approved.
Public security documentation
OperatingThis Trust Center is the public face of the program. It publishes the maturity of each practice area, the subprocessor list, disclosure routes and contact paths, and is maintained as the program changes.
- Pages carry a review date so customers can see how current the position is.
- Documents available on request are listed in the document library with their state and owner.
Security improvement program
OperatingSecurity work is planned and sequenced by technical leadership rather than handled reactively. The current phase prioritises documentation and evidence over new tooling.
- Priorities are driven by customer due-diligence findings, delivery risk and the gaps published on these pages.
- Progress is reflected by changing the status on the relevant page, not by announcing intent in advance.
Risk identification and tracking
In practiceSecurity risks are identified by technical leadership during architecture, infrastructure and project planning, and are addressed within delivery work. A consolidated risk register with owners, ratings and review dates is being built.
- Today, risk decisions are made and acted on but not centrally recorded, so trends across engagements are hard to see.
- The register will cover infrastructure, application, vendor and personnel risk in one place.
Security awareness across the company
In practiceAwareness is currently delivered through direct guidance from technical leads during project work. WebCastle is developing a structured awareness program with recorded completion.
- No formal training curriculum, completion tracking or phishing simulation exists today.
- Design covers credential handling, phishing and social engineering, device basics and reporting routes.
Framework alignment
Under EvaluationWebCastle is assessing which recognised framework to align its program to, using established control catalogues as a reference while policies are drafted. No certification or attestation is held.
- Alignment is being treated as a way to structure the program, not as a claim of compliance.
- The compliance page states WebCastle position on each framework explicitly.
Independent assessment
Under EvaluationIndependent security assessment — including third-party penetration testing and external audit — is being considered as the program matures. WebCastle does not currently commission formal third-party penetration tests.
- Customer-commissioned testing of a delivered application is supported and agreed per engagement.
Security metrics and management reporting
PlannedRegular reporting on security posture — open risks, access review completion, incident volume and program progress — is planned once the underlying records exist to report from.
Practice areas at a glance
Every security domain WebCastle publishes, its focus, and its current maturity. Each links to a page with the underlying controls.
| Domain | Focus | Status |
|---|---|---|
| Information Security | Governance, ownership, policy set, risk management and the improvement program | In Progress |
| Access Control | Account lifecycle, least privilege, multi-factor authentication and access reviews | In Progress |
| Application Security | Secure development, code review, dependency management and release practices | In Progress |
| Infrastructure Security | Cloud hosting, network boundaries, hardening, patching and logging | In Progress |
| Data Protection | Classification, encryption in transit and at rest, retention and deletion | In Progress |
| Incident Response | Detection, triage, escalation, customer notification and post-incident review | Developing |
| Business Continuity | Backups, restoration testing, recovery objectives and service continuity | Developing |
| Employee Security | Joiners, movers and leavers, confidentiality, devices and awareness | Developing |
| Vendor Security | Third-party selection, review, oversight, subprocessors and offboarding | Developing |
Implemented means the control set operates today. In Progress means it is partly in place and actively being formalised. Developing means practice exists informally while documentation is built. Under Evaluation means an approach is being assessed with no commitment made. Planned means it is committed to the roadmap but not yet started. No status on this site should be read as a certification or attestation.
Risk management
How security risk is identified and handled while a formal risk process is being established.
Where risk is identified
Risks surface during architecture and infrastructure decisions, code review, customer due-diligence questions, vendor adoption and incident handling. Technical leadership evaluates them in the context of the engagement affected.
How risk is judged
Assessment considers what data is exposed, whether the exposure reaches production or customer environments, how easily the weakness could be exploited, and what the customer contract requires. Judgement is currently applied by experienced engineers rather than scored against a published matrix.
How risk is treated
Risks are remediated within delivery work, mitigated by reducing access or scope, or accepted by technical leadership where the cost of remediation is disproportionate. Acceptance decisions affecting customer data are raised with the customer where the contract requires it.
What is being added
A consolidated risk register with named owners, agreed ratings and review dates is being built, so that accepted risks remain visible and treatment can be tracked to completion rather than held informally.
Customer-raised risk
Findings raised by a customer security review or a vulnerability report are treated as inputs to the same process, triaged through the security mailbox and tracked to resolution.
The improvement program
The sequence WebCastle is working through. Statuses on this site change when work completes, not when it is scheduled.
Publish an accurate position
CompleteEstablish this Trust Center, state the maturity of every practice area honestly, publish the subprocessor list, and provide clear routes for vulnerability reports and customer security questions.
Approve the core policy set
In progressDraft, review and approve the first tranche of written policies — information security, acceptable use, access control and vendor management — each with an owner, a version and an effective date.
Make existing controls evidenceable
In progressIntroduce access provisioning and removal records, joiner and leaver checklists with recorded completion, and a documented review record for newly adopted vendors, so that current practice produces evidence.
Establish review cycles
NextSet a defined interval for access reviews, vendor re-review and policy review, with a designated owner for each, and a recorded management review of security performance.
Consolidate risk and awareness
NextStand up the risk register and roll out the structured security awareness program with tracked completion, replacing the informal guidance model used today.
Seek independent validation
LaterOnce policies, records and review cycles are operating, evaluate independent assessment and framework alignment on their merits. Any certification will be announced only when it is actually held.
Policies, documents and review
The state of WebCastle security documentation and how often this site is reviewed.
- Policy status
- WebCastle security policies are in draft. No formally approved and signed-off Acceptable Use Policy, Employee Security Policy or Vendor Management Policy exists yet. Expectations in the meantime are set and enforced by technical leadership.
- Policy review cycle
- Once approved, each policy will carry an owner, a version and an effective date, and will be reviewed at a defined interval and after any material change to how WebCastle operates.
- Document availability
- Documents that exist are listed in the security document library with their state, owner and classification — public, on request, or internal. Documents shared on request are provided under an appropriate confidentiality arrangement.
- Trust Center review
- Every page carries the date its content was last reviewed. Pages are updated when a control changes status, when the subprocessor estate changes, or at the periodic review — whichever comes first.