Security is considered from discovery and architecture through development, deployment and maintenance. The objective is to reduce avoidable risk while keeping systems understandable, maintainable and appropriate for the client's operating context.
No responsible studio can promise that software will never contain a vulnerability or experience an incident. MURTWEB focuses on proportional controls, clear ownership, secure defaults and ongoing maintenance.
Security requirements are discussed before implementation. Authentication, authorisation, sensitive data, integrations, hosting, regulatory context and operational risks influence architecture from the beginning.
Applications can be designed around least privilege, role-based permissions, protected administrative functions and explicit authorisation for sensitive actions.
Depending on requirements, implementations may include secure password hashing, multi-factor authentication, account recovery controls, session expiry, secure cookies and established identity providers.
Typical measures include HTTPS in transit, protected secrets, restricted production access, minimal collection of personal data and clear retention rules. Encryption at rest is used when supported and justified by the selected infrastructure.
Server-side validation, output encoding, CSRF protection, upload restrictions and defensive handling of untrusted content are considered according to the application's attack surface.
Version control, peer or structured review, dependency review, controlled releases, separated environments, reproducible deployment procedures and testing form part of the delivery approach where included in scope.
Production credentials should not be stored in source code. Secrets are handled through environment configuration or an appropriate secret-management service. Production, staging and development environments should remain separated.
Third-party libraries are selected deliberately. Known vulnerabilities and unsupported dependencies should be addressed through maintenance rather than ignored after launch.
Where required, applications can include operational logging, error monitoring and alerting. Logs should avoid collecting unnecessary personal data or secrets.
Backups are not meaningful unless responsibility, frequency, retention and restoration procedures are defined. Backup and disaster-recovery arrangements must be agreed for each hosted system.
MURTWEB can support privacy-by-design principles such as data minimisation, purpose limitation and access controls. Legal compliance remains a shared responsibility and may require specialist legal review.
For supported systems, suspected incidents are assessed, contained and documented according to the agreed maintenance arrangement. Response times depend on the contracted support level.
Security is shared. Clients remain responsible for user governance, credential handling, device security, lawful data processing, third-party access and operational procedures under their control.
Yes, subject to review and agreement.
No. Absolute security cannot be guaranteed. The goal is to reduce risk through appropriate controls and maintenance.
Only when a defined test is included in the engagement, or when an independent specialist is engaged. Otherwise, this is available as an optional service.
Where practical, production accounts and access policies should remain under the client's control.
Through an agreed maintenance plan defining responsibility, priority and response expectations.
Only when explicitly included in hosting or maintenance scope.
Tell MURTWEB about the data, users, integrations and operational risks involved. A proportionate security approach can then be defined for the project.