Authentication
How identity is established: local accounts, an organisation's identity provider or single sign-on. Session lifetime, password and multi-factor requirements are decided per project and its integration options.
Security & Governance
Security Is Designed In, Not Added at the End.
We identify who uses a system, what data it holds, which actions matter and who operates it. Those answers become requirements for identity, authorization, records, hosting and testing, agreed per project rather than promised in general.
This page describes how we approach security engineering. It is not a certification, an audit report or a statement that any particular control exists in a particular system.
Explore the permissions exampleConcept diagram
- RequestA person or system asks to act
- IdentityWho is this, and how was that established?
- Authorization, on the serverMay this role do this, to this record, in this tenant?AllowRefuse
- Data and actionOnly the permitted scope is read or changed
- RecordSignificant outcomes are recorded where required
Where requirements come from
Security Starts With Clear Responsibilities.
Security requirements are not a fixed checklist. They follow from the people, data, actions and operating model of a specific system, and from the client's own policies, contracts and regulators.
- 01
People
Who signs in: staff, managers, administrators, clients, partners, service accounts. How identities are created, changed and removed.
- 02
Data
What is stored and how sensitive it is: personal data, financial records, documents, credentials. Where it lives and who may see it.
- 03
Actions
Which operations carry consequence: approvals, exports, deletions, permission changes, payments. Which need a second person or a record.
- 04
Operations
Who hosts, patches, monitors, backs up and responds after release. These responsibilities are agreed in writing, not assumed.
Identity and access
Protecting Access and Sensitive Information.
Hiding a button is not access control. The interface can reflect permissions, but authorization must be enforced on the server. Direct endpoint requests need the same checks as actions through the interface.
Authorization and least privilege
Define permissions by role, record ownership and tenant, including narrow service-account scopes and access reviews. Administrator powers need explicit limits, not an automatic bypass of business rules.
Sensitive data and documents
Identify which fields and files require restricted visibility, controlled downloads, encryption in transit and at rest, or masking. Required protection and its verification depend on the particular system.
Environment and configuration
Define development, test and production boundaries, secure configuration, secret handling and privileged access. The arrangement must fit the deployment rather than be assumed identical across systems.
| Action | Employee | Manager | Administrator |
|---|---|---|---|
| Submit own expense claim | Allowed | Allowed | Configurable |
| View team claims | Not allowed | Own team only | Configurable |
| Approve a claim | Not allowed | Team, not own claims | Not allowed |
| Change user roles | Not allowed | Not allowed | Allowed, recorded |
| Export all claims | Not allowed | Not allowed | Configurable |
Records and logs
Important Actions Should Leave a Clear Record.
We agree which actions are significant, what each record must contain, who may read it, how long it is kept and how it is protected from unauthorised change. We do not claim that every event is captured.
Business audit trail
Answers: who decided what, and why?
Approvals, status changes, edits to important records, with the reason given. Read by managers, auditors and the business.
Security log
Answers: what happened to the system?
Sign-ins, failed attempts, permission changes, refused requests, configuration changes. Read by IT and security staff, often in their own tools.
Fictional example event
- Event
- Expense claim approved
- Actor
- Manager, user ID 4127
- Record
- Claim EXP-20931, Finance team
- Change
- Status: Submitted to Approved
- Reason
- Receipts match the travel policy
- When
- 2025-03-14 09:42:17 UTC
- Outcome
- Approved
Depending on the requirement, records can include actor, action, resource, timestamp, outcome and relevant context or correlation IDs. Minimize personal data, exclude secrets, restrict log access and agree retention and monitoring responsibilities.
Hosting and responsibility
Data Ownership, Hosting, and Responsibilities Should Be Clear.
We support four deployment models. Which one fits depends on the product or project, its technical feasibility and what is agreed in the contract. No single model is available for every product.
- A
Client-controlled infrastructure
Deployed into the client's own environment. The client typically controls infrastructure access and its policies. Our access is agreed and can be limited.
- B
Weblysoft-managed deployment
We operate the deployment on an agreed provider. The scope of operation, such as updates, monitoring and backups, is written down rather than implied.
- C
Hosted SaaS products
Products Weblysoft designs and operates itself. Data handling follows that product's service and data terms, which differ from a custom engagement.
- D
Third-party infrastructure
Deployed with an external provider chosen with the client. Provider terms, configuration and data boundaries are reviewed for that provider.
Data ownership, access, export and deletion terms need explicit agreement. Custom software rights, Weblysoft-owned product licences and third-party rights are different; a hosted-product subscription does not by itself transfer its source code.
Tenant boundaries in shared systems
Where several organisations use one system, separation is an architecture decision we evaluate, not a guarantee we assume.
- Assess tenant-scoped authorization for server-side data access.
- Do not rely on browser-provided identifiers alone to determine access.
- Include files, exports, search indexes and caches in boundary requirements.
- Define cross-tenant denial tests alongside permitted user paths.
- Evaluate appropriate resource separation; no dedicated database, physical isolation or residency guarantee is implied.
| Responsibility | Question to agree | Owner |
|---|---|---|
| Infrastructure and deployment | Who configures the environment, holds privileged access and authorizes releases? | To be agreed |
| Updates and patching | Who applies operating system, runtime and dependency updates, and when? | To be agreed |
| Backups and recovery | What is backed up, how often, and who tests a restore? | To be agreed |
| Monitoring and incidents | Who watches alerts, who is contacted, and what are each party's obligations? | To be agreed |
| Data retention and export | How long is data kept, how is it deleted, and in what form can it be returned? | To be agreed |
| Application and user access | Who validates application controls, provisions users, approves role changes and reviews access? | To be agreed |
Specific security and operational responsibilities are agreed according to the project's hosting model, scope, and contract.
Secure engineering
Security Requirements Influence Engineering Decisions.
These areas guide the engineering scope to agree for a system. Which controls and tests apply depends on risk, architecture and contract; this is not evidence that every activity is performed in every engagement.
1Identity and access
Specify authentication, sessions, privileged access and role, record and tenant boundaries. Define permitted and refused actions and the tests needed to validate the agreed rules.
2Sensitive data
Assess data classification, minimum necessary collection, transport and storage encryption requirements, document visibility, retention, export and deletion. Verify the chosen controls for the specific system.
3Secure application development
Agree input validation, parameterised queries, output encoding, upload restrictions, API authorization and safe error handling. Define dependency review, vulnerability checks and risk-focused code review as applicable to the scope.
4Logging and auditability
Select significant business and security events, required fields, retention and access controls. Agree who reviews alerts and records, and test the required coverage without recording secrets or unnecessary personal data.
5Third parties and AI
When an external API or AI model processes information, we establish what data leaves the system, the provider's retention and training terms, and what the integration is permitted to do.
- Send the minimum data needed, and only data the requesting user may see.
- Treat documents, emails and web content as possible prompt injection: they cannot grant permissions or trigger actions on their own.
- Validate model output before it changes records; human review is matched to the consequence of an error.
- Review each provider's retention, location and contractual terms; they differ, and none is assumed.
6Deployment and operations
Define environment separation, secret handling, configuration, release permissions and maintenance access. Agree backup/recovery, monitoring and incident responsibilities rather than assuming an identical operating model for all systems.
Security Controls Need to Be Tested.
Recognized guidance such as OWASP ASVS and API Security can inform the agreed review criteria. Referencing OWASP guidance is not certification or proof of compliance.
- Engineering tests
- Agree authentication and permission tests, input/API checks, dependency/configuration review, audit-event validation and sensitive-workflow acceptance tests. Include cross-tenant denial checks where relevant.
- Independent assessment
- Penetration testing is a separate service, scoped and commissioned separately, and performed by specialists the client or Weblysoft engages. It is not automatically included.
- Review boundaries
- Software engineering validation is not an independent audit or formal compliance opinion. Specialist assessments, certification work and required evidence need their own scope.
Documentation is agreed in scope: for example permission maps, data-flow notes, deployment/configuration notes and records of tests performed. No standard security evidence package is promised by default.
Evidence and context
Security Considerations in Real Projects.
Weblysoft delivered the corporate website and content-management work for Bank of Africa UK. The public homepage below shows that project. It is not evidence of any security control, assessment or certification at the bank.
Considerations by sector
Serving an organisation in a sector does not make Weblysoft or its products compliant with that sector's rules. These are the questions we raise; the obligations are confirmed with the client and its advisors.
- Financial services
- Segregation of duties, approval records, outsourcing and third-party expectations from the client's regulator.
- Legal
- Matter-level confidentiality, conflict walls, privileged documents and who may see which client's files.
- Professional services
- Client-by-client separation, contractor access and the handling of engagement documents.
- Healthcare operations
- Non-clinical systems such as scheduling and transport still touch personal data; applicable health-data rules are identified before design.
- Public sector
- Procurement security requirements, data location, accessibility and records obligations set by the contracting body.
Questions buyers ask
Can you develop software for our cloud environment?
Client-controlled and third-party infrastructure are supported deployment models. Compatibility, access, provider constraints and responsibilities must be assessed for the particular application and agreed before committing.
Who is responsible for security after launch?
Client, Weblysoft and provider responsibilities follow the hosting model, scope and agreement. Updates, access reviews, monitoring, incidents and recovery need named owners; support and response commitments are not implied.
Can our IT or security team participate?
Yes. Involve your stakeholders in defining requirements, reviewing proposed boundaries and agreeing validation criteria. Their participation and any formal reviews are scoped with the engagement.
Can permissions and audit trails be included?
They can be defined as application requirements. Role rules, significant events, retention, protection and tests must be agreed and verified for the system; this does not mean every product already has the same controls.
Does Weblysoft guarantee regulatory compliance?
No blanket guarantee is made. Obligations depend on the application, data, jurisdiction and operating model. SOC 2, ISO 27001 or other certification is not claimed here; independent assessments and formal compliance advice require separate evidence and scope.
Next step
Let's Review Your Security Requirements Before We Build.
Describe the users, the data and your hosting constraints. We will say plainly what we would design, what would need to be agreed and where independent assessment belongs.
An initial requirements conversation, not an independent audit, penetration test, certification assessment or formal compliance review.