Standards, compliance and application security.

The standards below apply to every departmental system we build. They are applied from the start of development rather than addressed before launch.

Standards we build to

The standards a departmental system is measured against.

Hosting & data residency

Deployment

Deployed to state, departmental or Indian data centre infrastructure as the requirement specifies. Hosting and pre-go-live audit are arranged through the relevant state agencies, such as APTS and APSDC, where applicable. The deployment topology is documented and handed over.

GIGW 3.0

National

Guidelines for Indian Government Websites — mandatory page furniture, metadata, archival policy, contact and grievance disclosure, and consistent navigation across the site.

WCAG 2.1 level AA

Accessibility

Web Content Accessibility Guidelines (WCAG) 2.1 level AA — keyboard operability, contrast ratios, form labelling, screen-reader semantics and text resizing, verified with assistive technology in addition to automated testing.

DPDP Act, 2023

Data protection

Purpose limitation, consent capture, retention limits and breach-notification readiness designed into any system that holds citizen personal data.

CERT-In security audit

Assurance

Pre-go-live VAPT through a CERT-In empanelled auditor, with findings closed and re-tested before the system is opened to the public.

IT Act, 2000 & CERT-In directions

National

Reasonable security practices under Section 43A, with incident reporting, log retention and monitoring handled in line with the CERT-In directions that apply to government systems.

Bilingual by default

Language

English and Telugu content structures, fonts and input handling planned at design stage rather than added as a later translation pass.

Security practice

Security controls, mapped and verifiable.

We develop against the OWASP (Open Web Application Security Project) Top 10, a widely used reference for web application security risks. Each control below is mapped to the risk category it addresses and can be verified in the source code we hand over.

Parameterised database access

A03 · Injection

All queries use prepared statements with bound parameters, addressing SQL injection at the data access layer rather than by input filtering.

Hashed credentials

A02 · Cryptographic Failures

Passwords are stored as bcrypt hashes. They are not reversibly encrypted and cannot be recovered from the database; they can only be reset.

CSRF protection on state changes

A01 · Broken Access Control

Every administrative form that writes data carries a per-session token, so a request forged from another site cannot act on a logged-in officer's behalf.

Hardened sessions

A07 · Authentication Failures

Session identifiers regenerated on login to prevent fixation; cookies set HttpOnly, SameSite and Secure so they cannot be read by scripts or sent cross-site.

Uploaded documents never served directly

A01 · Broken Access Control

Files containing personal data are not publicly served. They are streamed only to an authenticated user with rights to them; a direct URL returns no content.

Output escaping by default

A03 · Injection (XSS)

Dynamic values are escaped on output through a single helper, addressing cross-site scripting at the point of rendering rather than relying on input sanitisation.

Security & data protection

Security protocols and data protection measures.

These apply to every departmental system we build, at state or central level. Where a department specifies its own standard, we work to that instead.

Transport security — HTTPS over TLS 1.2 / 1.3 only, with HSTS enabled and older protocols and weak ciphers disabled
Encryption at rest — AES-256 for sensitive fields and for database backups
Credential storage — bcrypt password hashing with per-user salt; credentials are never stored reversibly or logged
Response headers — Content-Security-Policy, X-Frame-Options, X-Content-Type-Options and Referrer-Policy set on every response
Access control — role-based permissions by designation on least privilege, applied to application and database accounts alike
Audit logging — who changed what and when, with digital platform and application logs retained for 180 days within Indian jurisdiction as the CERT-In directions require
Clock synchronisation — system clocks synchronised to NIC or NPL NTP servers, so log timestamps stand up in an investigation
Incident reporting — defined route for containment and reporting to CERT-In within six hours of a reportable incident being noticed
Data minimisation and retention — only the personal data the service requires, held only as long as the stated purpose needs, with consent captured where the DPDP Act requires it
Backups and recovery — scheduled encrypted backups with a restore that is actually rehearsed, not assumed
Secure development — code review before release, dependencies kept patched, and VAPT by a CERT-In empanelled auditor before go-live

Applies to

State & central government systems

Same measures regardless of tier

Statutory basis

DPDP Act 2023 · IT Act 2000 · CERT-In directions

With GIGW 3.0 and WCAG 2.1 level AA for public-facing services

More for government