Most teams treat the Information Security Assessment (ISA) spreadsheet like a hurdle to clear once, then file away. That's why the first TISAX audit interview surfaces gaps the self-assessment should have caught months earlier. The ISA isn't a compliance artifact you complete and forget. It's a diagnostic tool that reveals how well your ISMS actually works. Misusing it sets you up for a painful Assessment Level 2 or 3 experience.
Here's what keeps going wrong and how to fix it before your assessor asks the questions you can't answer.
Common Mistakes in TISAX Self-Assessments
The ISA spreadsheet (currently version 6.0.3) looks like a questionnaire, so teams treat it like one. They assign it to someone junior, answer the questions in isolation, and move on. But TISAX assessors don't just read your answers. At AL2, they conduct remote plausibility checks to verify your descriptions match reality. At AL3, they visit your facilities and interview control owners to verify operating effectiveness. If your self-assessment doesn't reflect what's actually happening, the disconnect surfaces immediately.
Another issue is that most organizations don't understand that assessment objectives determine which tabs of the ISA you need to complete. If you've selected Information Security objectives (like Confidential or High Availability), you only complete the Information Security tab. Add Prototype Protection or Data Protection objectives, and you're completing additional sections. Teams often complete the wrong sections or skip required ones because they haven't mapped customer requirements to assessment objectives first.
Mistake 1: Completing the Self-Assessment Before Defining Scope
Why it happens: Teams download the ISA spreadsheet and start filling it out without confirming which assessment level and objectives their customers actually require.
The consequence: You spend weeks documenting controls for Prototype Protection when your customer only specified "Confidential" (Assessment Objective 2, which is Information Security only). Or you complete an AL2-level self-assessment when your customer contract requires AL3 full verification. The mismatch wastes preparation time and creates audit delays when you realize you're pursuing the wrong label.
The fix: Before you open the ISA, collect your customer requirements in writing. Which assessment objectives did they specify? Do they require AL2 plausibility checks or AL3 on-site verification? Map those requirements to the table of twelve assessment objectives. Information Security objectives (1-6) require only the Information Security tab. Prototype Protection objectives (7-10) add the Prototype Protection tab. Data Protection objectives (11-12) add the Data Protection tab. Your scope determines your workload.
Mistake 2: Writing Implementation Descriptions That Don't Answer "Who, What, When, Where, How"
Why it happens: Teams write high-level policy statements instead of describing actual operational processes. An implementation description might say "We follow our access control policy" without explaining who provisions accounts, what approval workflow they use, when reviews happen, or how deprovisioning works.
The consequence: When the assessor conducts the plausibility check (AL2) or on-site interview (AL3), they ask control owners to walk through the process. If your description doesn't match what the control owner describes, you've created a credibility gap. Assessors start probing deeper, and what should have been a straightforward verification becomes an investigation into whether your documented controls exist at all.
The fix: For each control area, document the operational reality: "The IT manager reviews access requests submitted via ServiceNow ticket. Approvals require the employee's direct manager and the data owner. Provisioning happens within 24 hours of approval. Quarterly access reviews are scheduled via calendar reminder, and the CISO reviews the attestation log." Reference the specific tools, roles, and timelines your team actually uses. If you can't describe the "who, what, when, where, how," your control isn't mature enough for TISAX yet.
Mistake 3: Treating Maturity Level 3 as the Ceiling
Why it happens: Teams read that maturity level 3 (documented, followed, integrated standard process) is the target and stop there. They don't realize that TISAX assessors expect continuous improvement evidence, especially at AL3.
The consequence: Your processes are documented and followed, but you have no metrics, no improvement cycles, and no evidence that you're learning from incidents or near-misses. At AL3, assessors look for maturity level 4 indicators (quantitatively managed processes with performance metrics) and maturity level 5 indicators (optimizing processes with continuous improvement). If you've plateaued at level 3 across the board, you're signaling that your ISMS is static, not evolving.
The fix: For critical control areas, build measurement into the process from the start. Track access review completion rates. Measure mean time to patch critical vulnerabilities. Log security awareness training completion percentages and phishing simulation click rates. In your ISA findings/result column, note where you're tracking performance and where you've made process improvements based on data. You don't need level 5 maturity everywhere, but showing improvement momentum in high-risk areas demonstrates ISMS maturity that goes beyond checkbox compliance.
Mistake 4: Leaving the Findings/Result Column Blank
Why it happens: Teams misunderstand the findings/result column as something the assessor completes, not the auditee. They leave it blank or write "no findings" across the board.
The consequence: You've missed the opportunity to demonstrate self-awareness and gap remediation. Assessors expect you to identify your own weaknesses and document remediation plans. When you claim perfection, they dig harder to find what you missed. An empty findings column signals you didn't actually use the ISA as a diagnostic tool.
The fix: Use the findings/result column to document real gaps and in-progress improvements. "Policy documented but annual review not yet scheduled" or "Access review process in place but automated reporting not implemented" shows you understand where you are on the maturity curve. For each gap, reference your risk treatment plan or improvement roadmap. This isn't about admitting failure. It's about showing you have visibility into your ISMS and a plan to mature it.
Mistake 5: Treating the ISA as a One-Time Deliverable
Why it happens: Teams complete the self-assessment, submit it to the assessor, and don't touch it again until the next audit cycle.
The consequence: Your ISMS evolves. You implement new tools, change approval workflows, update policies, or shift responsibilities between teams. None of those changes make it back into the ISA. When the assessor conducts interviews six months after you submitted the self-assessment, your documented controls don't match current operations. You're now explaining discrepancies under audit pressure instead of maintaining accurate documentation as a normal ISMS practice.
The fix: Integrate ISA updates into your change management process. When you update a policy, update the corresponding ISA implementation description and reference documentation. When you implement a new security tool, update the relevant control descriptions. Schedule quarterly ISA reviews where control owners verify their sections still reflect reality. Treat the ISA like your risk register or asset inventory: it's only useful if it's current. This approach also makes your next TISAX assessment dramatically easier, because you're maintaining audit-ready documentation year-round, not scrambling to reconstruct six months of changes when the next audit is scheduled.
Prevention Checklist
Before you start your next ISA update:
- Confirm assessment level and objectives in writing from each customer requiring TISAX
- Map objectives to ISA tabs (Information Security, Prototype Protection, Data Protection)
- Assign control owners by ISA section, not just one person for the entire spreadsheet
- Require implementation descriptions to include who, what, when, where, how for each process
- Populate reference documentation columns with specific policy names, procedure numbers, system screenshots, or configuration exports
- Use findings/result column to document known gaps and link to risk treatment plans
- Identify at least three control areas where you'll track performance metrics (maturity level 4+)
- Schedule quarterly ISA reviews with control owners to verify accuracy
- Update ISA within 30 days of any material ISMS change (policy updates, tool implementations, process changes)
- Conduct a mock plausibility check internally: have someone not involved in ISA completion interview control owners and compare answers to documented descriptions
The teams that pass TISAX assessments without major findings aren't the ones with perfect security programs. They're the ones who use the ISA as it's designed: a living diagnostic that keeps your documented controls aligned with operational reality. Treat it that way from the start, and your Assessment Level 2 plausibility check or Assessment Level 3 on-site verification becomes a validation of work you've already done, not a discovery process that surfaces gaps you should have caught yourself.
