A business application security discussion becomes more useful when it names the records, actions and people involved. A request for a secure ERP is difficult to accept or reject. A requirement that a branch employee cannot view another branch's customer export is specific enough to implement and test.
This guide helps a company prepare the security portion of an ERP or custom software brief. The scope should reflect the application and its data; a completed checklist is not proof that every possible risk has been removed.
Start with the records and decisions that matter
List the information the application stores and the important actions it enables. Include attachments, report exports, background jobs and administrative screens. Identify who owns each business rule and who can approve an exception.
Consider normal work and misuse separately. A sales employee may need to view an assigned account, while changing its credit terms requires a different responsibility. An external customer may be allowed to download one document without receiving access to the internal customer record.
Write these decisions as examples the delivery team can discuss. Avoid using real customer details in initial demonstrations; use representative test records with the same structure.
Define access by action and scope
For each role, specify permitted actions and the records they apply to. Distinguish viewing, creating, editing, approving, exporting and managing other users. Add the relevant scope, such as a branch, legal entity, assigned account or project.
The OWASP authorization guidance recommends denying access by default and checking permissions on every request. Hiding a button is therefore insufficient evidence that an action is protected; enforcement needs to apply when the server receives the request.
For example, create two fictional branches with separate orders. Test that each employee can perform the intended work in their own branch, then verify that direct requests for the other branch's order, attachment and export are rejected. Record both allowed and rejected cases. Repeat the checks after a role is changed.
Agree how temporary access starts, expires and is reviewed. If a support account requires elevated access, define its approval and removal process rather than relying on a permanent shared administrator login.
Include integrations and operational accounts
An integration is another actor with its own purpose. Document what it reads or changes, which environment it connects to and who owns its credentials. Separate test and production connections so that a demonstration cannot accidentally operate on live records.
Ask how credentials are supplied to the application, rotated and removed when the integration is retired. Include scheduled tasks and external support tools in the inventory. A successful connection proves connectivity; it does not establish whether its permissions are appropriate.
For an order synchronization, specify what happens when a request is retried or arrives twice. Reconcile the source and destination records using stable identifiers. These operating rules reduce the chance that an incident investigation confuses duplicated processing with a legitimate business action.
Agree the verification scope before acceptance
OWASP ASVS provides a framework of application security requirements that can support development, testing and procurement. If it is used in the project, agree the version, applicable requirements and evidence expected. Mentioning the standard alone does not establish that an application was assessed against it.
Request an issue list with affected behavior, severity rationale, owner and retest outcome. Distinguish resolved findings from accepted limitations. Define who can accept a remaining risk on behalf of the business and what operating constraint applies while it remains open.
Keep test evidence tied to a release and environment. A report for an earlier version may not cover a newly added export, integration or administrator screen. Decide which changes require targeted retesting and when an independent assessment is appropriate for the project's risk and contractual requirements.
Make security part of the operating handover
A handover should name the people responsible for application updates, dependency review, account administration, monitoring and incident coordination. Specify the support hours and escalation route actually agreed in the contract.
Prepare a response exercise around a realistic scenario, such as an exposed integration credential. Identify who can revoke access, investigate affected actions and communicate with the business owner. Keep sensitive records out of routine support messages and preserve the evidence needed for the investigation.
Coordinate this plan with the cloud hosting and recovery guide. The application team and hosting team need a shared understanding of the recovery sequence and the business checks required before service resumes.
Review Tarawud's security information and procurement information when preparing a supplier discussion. For custom software or ERP and Odoo implementation, contact Tarawud with the planned users, data categories and integration boundaries so the proposal can define a concrete security scope.
