Pre-security-assessment checklist

Why pre-assessment preparation is its own phase

Security assessments—penetration tests or independent audits—often appear as a single contract line, yet they require weeks of coordination. Starting unprepared produces piles of known findings, hides architectural gaps and drains team morale. A pre-assessment checklist turns the exercise into a maturity measurement.

Aksiyon Soft ties this list to Definition of Done and go-live gates on enterprise software and customer portal work.

• • •

Authentication and session management

Assessors focus on login mechanics on day one. Verify:

• MFA enforced for critical roles?
• Password policy and lockout aligned with central identity?
• Session lifetime, idle timeout and secure logout defined?
• SSO token refresh and revocation tested?

For portals, align with our SSO and session security guide.

Authorization and data boundaries

“I can log in” is not enough—you must prove users cannot see each other’s data. Is the role and scope model documented and consistent with RBAC design? Do automated tests cover horizontal privilege escalation (changing ids to access other records)?

Do unauthorized API calls return consistent 401/403 without leaking internals?

• • •

Logging, monitoring and incident response

Auditors ask about operations, not only code. Are auth failures, unauthorized attempts and admin actions logged? Are secrets and personal data masked? Is log access role-based?

Observability pays off here—without alerts, runbooks and escalation paths, findings stay open.

Dependency surface and supply chain

• Known CVE scanning in CI?
• SLA for critical findings?
• Secrets in a vault, not the repo?
• Production vs test separation; default passwords removed?

Data protection and compliance

Privacy and sector rules expect encryption in transit (and at rest where needed), backups, access records and deletion procedures. Is data classified (personal, financial, operational)? Is scope clear—which environment and dataset will be tested?

API and integration security

Public APIs need rate limits, authentication and contract discipline. Does API documentation include security? Are webhook signatures and replay protection in scope?

Assessment day organization

Give testers current architecture diagrams, role matrices, test accounts and known constraints (IP allow lists, maintenance windows). Include a business representative for triage; document accepted risks. Plan a remediation sprint before closing the report.

See solutions and custom software development for typical delivery scope—discuss security prep during discovery.

One-page summary checklist

• Identity, session, MFA
• RBAC and horizontal access tests
• Logs, alerts, runbooks
• Dependencies and secrets
• Data classification and backups
• API surface and integrations
• Remediation ownership and dates

Vendor coordination

Pen-test vendor, development partner and internal IT should share one triage channel. A signed RACI before testing starts avoids “whose bug is this” delays. Define hotfix branch policy and emergency approval paths in writing.

Prioritising findings and accepting risk

Once the assessment report arrives, weigh the business impact of each finding as well as its CVSS score. An item with a low technical score but a high data-leak risk comes first. Risk-acceptance decisions must be recorded with the signature of senior management or an assigned risk owner; a “we will look at it later” note does not hold up in an audit.

If no capacity is reserved for a remediation sprint, findings age and the same items reappear in next year’s test. Security debt, like technical debt, should be a visible backlog item.

Third parties and the shared responsibility model

SaaS dependencies, identity providers and the hosting provider’s shared responsibility matrix are all in scope. Where does the data live, who holds the backups, is there a sub-processor agreement? Answer these questions during preparation. A penetration test targets configuration mistakes as well as the application layer: open storage buckets, wrong CORS settings, debug mode left on.

Test environment and synthetic data

Real customer data should not be used in a penetration test; prepare a synthetic or masked data set. Define separate test accounts for each role (administrator, standard user, integration service) and rotate the passwords when the assessment is over.

Staging security configuration must not be looser than production. Admin panels or debug endpoints left open because “it is only test” make up half of the findings. Apply the same checklist to staging.

Continuity after the assessment

Instead of a one-off test, plan a yearly repeat or a short test before each major release. Adding SAST and DAST steps to the CI/CD pipeline reduces regression risk. When security requirements are written into the Definition of Done, new features do not reopen old vulnerabilities.

A one-page security status summary for the board: number of open critical findings, average time to close, date of the last dependency scan and date of the next assessment. This summary can be a standing agenda item at project steering meetings.

When a customer or auditor requests the report under NDA, the redaction process should be defined in advance; the raw penetration report should never be shared.

Summary

A pre-assessment checklist improves readiness, not just finding counts. Cover portal, API and operations together; tie results to the product roadmap. Reach us via contact.