The contract is signed. The vendor is eager to get you live. Your internal stakeholders are impatient. Everyone wants to skip straight to deployment.

This is exactly when security gets forgotten.

Application onboarding is when you establish access controls, configure security settings, and set monitoring baselines. Decisions made during onboarding persist for years. The admin account created during setup with a shared password gets forgotten. The overly broad permissions granted “temporarily” become permanent.

This checklist covers what IT and security teams should verify before and during application deployment. It’s designed to be practical—things that actually matter, not compliance theater.

Before You Start: Pre-Onboarding

Some items should be settled before onboarding begins.

Verify Security Assessment Was Completed

Before procurement approved this application, there should have been a security review. Verify:

• [ ] Vendor questionnaire completed
• [ ] SOC 2 report (or equivalent) reviewed
• [ ] Data classification determined (what data will this application access/store?)
• [ ] Risk level established (Tier 1/2/3)
• [ ] Any conditions from security review documented

If this wasn’t done, stop. Complete the assessment before onboarding. Post-deployment discovery of security gaps is more painful than pre-deployment delay.

Understand What You’re Integrating

Before configuring, understand the application’s security-relevant features:

• [ ] What authentication methods does it support? (SSO? MFA? Local accounts?)
• [ ] What data will it access or store?
• [ ] What integrations does it require? (OAuth to your identity provider? API access to other systems?)
• [ ] What admin capabilities exist?
• [ ] What logging/audit capabilities exist?
• [ ] What’s the vendor’s security configuration guide (if any)?

Many applications have security hardening guides. Find and read them.

Designate Ownership

• [ ] Application owner designated (business stakeholder)
• [ ] Technical administrator designated
• [ ] Security contact for this application designated

Every application needs someone accountable. Unowned applications accumulate security debt.

Identity and Access Management

The most common onboarding failures involve access control. Get this right.

Single Sign-On (SSO)

If the application supports SSO, use it.

• [ ] SSO integration configured (SAML/OIDC)
• [ ] SSO tested with representative users
• [ ] Local authentication disabled (if possible)
• [ ] SSO-bypass methods identified and controlled (break-glass procedures)

Common oversight: SSO is configured, but local accounts still work. This means users can bypass SSO controls. Disable local authentication if the vendor allows it. If not, monitor local login attempts.

Common oversight: SSO is configured for regular users but admin accounts still use local authentication. Admins especially need SSO and MFA.

Multi-Factor Authentication (MFA)

• [ ] MFA enabled for all users (or enforced via SSO)
• [ ] MFA required for administrators
• [ ] Weak MFA methods disabled if not needed (SMS, email codes)
• [ ] Recovery/bypass procedures documented

If the application has its own MFA (not via SSO), configure it according to your organization’s MFA standards.

User Provisioning

• [ ] User provisioning process defined (manual, JIT, SCIM)
• [ ] SCIM integration configured if supported
• [ ] User deprovisioning process defined and tested
• [ ] Group/role synchronization configured if applicable

Common oversight: Provisioning is set up; deprovisioning isn’t. Terminated employees retain access to the new application because nobody told it they left. Test deprovisioning explicitly.

Administrator Access

• [ ] Admin accounts created only as needed (least privilege)
• [ ] Admin accounts tied to named individuals (not shared)
• [ ] Admin account inventory documented
• [ ] Admin accounts use SSO/MFA
• [ ] Break-glass admin process defined

Common oversight: The initial setup uses a shared admin account that never gets replaced with named accounts. Create named admin accounts immediately; deprecate the shared one.

Role and Permission Configuration

• [ ] Default roles reviewed for appropriateness
• [ ] Custom roles created if needed for least privilege
• [ ] Excessive default permissions reduced
• [ ] Role assignment process defined

Many applications have overly permissive default roles. Review what each role can do. Create limited roles if the defaults are too broad.

Data Security Configuration

Understand how data flows and is protected.

Encryption

• [ ] Data encrypted in transit (TLS verified)
• [ ] Data encrypted at rest (verify with vendor)
• [ ] Encryption key management understood (vendor-managed? customer-managed keys?)

For sensitive data, customer-managed keys provide additional control but add complexity. Match the approach to data sensitivity.

Data Residency

• [ ] Data storage location verified (region/country)
• [ ] Compliance with any data residency requirements confirmed
• [ ] Subprocessor locations understood

If you have data residency requirements (GDPR, specific customer contracts), verify where data lives.

Data Sharing and Export

• [ ] Understand what data the vendor can access (support, telemetry, etc.)
• [ ] Disable unnecessary data sharing options
• [ ] Configure data export restrictions if applicable
• [ ] Understand data retention settings and configure appropriately

Integration Data Flows

• [ ] Document what data flows to/from this application
• [ ] Verify integrations only access necessary data
• [ ] OAuth scopes limited to minimum needed
• [ ] API permissions scoped appropriately

Logging and Monitoring

You can’t detect problems in applications you can’t see into.

Audit Logging

• [ ] Audit logging enabled
• [ ] All relevant events captured (login, admin changes, data access, etc.)
• [ ] Log retention configured per your requirements
• [ ] Log export configured (to SIEM if Tier 1 application)

Common oversight: Audit logging exists but isn’t exported. Logs sit in the vendor’s console. When an incident occurs, you discover 30-day retention has deleted what you need. Export logs to your own systems.

Alerting

• [ ] Alerts configured for critical events (admin changes, security config changes)
• [ ] Alert recipients designated
• [ ] Baseline of normal activity established

For Tier 1 applications, configure alerts directly in the application and in your SIEM.

Monitoring Integration

• [ ] Application added to monitoring/inventory systems
• [ ] Health checks configured if applicable
• [ ] Security monitoring integrated (CASB, SIEM, etc.)

Security Configuration

Most applications have security settings beyond the defaults. Configure them.

Session Management

• [ ] Session timeout configured appropriately
• [ ] Concurrent session limits set if available
• [ ] Session termination on password change configured

Password Policy (if local auth used)

• [ ] Minimum length meets requirements
• [ ] Complexity requirements appropriate
• [ ] Password reuse prevention enabled
• [ ] Account lockout configured

API Security

• [ ] Unnecessary API access disabled
• [ ] API keys use appropriate scopes
• [ ] API rate limiting configured if available
• [ ] API key rotation scheduled

Network Security

• [ ] IP allowlisting configured if appropriate
• [ ] Private connectivity options evaluated (VPN, PrivateLink)
• [ ] Unnecessary network exposure reduced

For high-risk applications, consider network-level restrictions on who can access the application.

Testing

Don’t trust—verify.

Functional Testing

• [ ] SSO login works for test users
• [ ] MFA prompts as expected
• [ ] Role permissions work as configured
• [ ] Provisioning/deprovisioning works

Security Testing

• [ ] Attempted access with disabled account fails
• [ ] Attempted access without MFA fails (if required)
• [ ] Role boundary enforcement verified (user can’t access admin functions)
• [ ] Audit logs capture expected events

Verify your security configurations actually work. Misconfiguration often isn’t apparent until tested.

Documentation and Communication

Record what you did and tell people about it.

Documentation

• [ ] Configuration decisions documented
• [ ] Admin procedures documented
• [ ] Support escalation paths documented
• [ ] Security incident response procedures for this application documented

Communication

• [ ] End users informed of new application and how to access
• [ ] Helpdesk briefed on common issues
• [ ] Security team aware of application and risk tier
• [ ] Relevant policies updated (if needed)

Post-Onboarding

Onboarding isn’t over when users get access.

30-Day Review

• [ ] Review initial usage patterns
• [ ] Verify provisioning/deprovisioning is working
• [ ] Check for security misconfigurations discovered in operation
• [ ] Gather user feedback on access issues

Ongoing

• [ ] Schedule periodic access reviews
• [ ] Include in vulnerability and patching scope (if applicable)
• [ ] Add to vendor renewal review schedule
• [ ] Include in disaster recovery planning (if applicable)

The Checklist You Actually Need

For quick reference, here’s the condensed version:

Identity:

• SSO configured and local auth disabled
• MFA required for all users
• Named admin accounts (no shared accounts)
• Deprovisioning tested

Data:

• Encryption verified
• Data location acceptable
• Integrations scoped minimally

Monitoring:

• Audit logging enabled and exported
• Critical alerts configured

Configuration:

• Session timeout set
• API access scoped appropriately
• Vendor hardening guide followed

Testing:

• Security configurations verified by testing

Documentation:

• Configuration and procedures documented

Skip items on this list at your own risk. The configuration you forget during onboarding becomes the gap you discover during an incident.