IT System Architecture Assessment

Audit of quality, security, and resilience of internal systems and public applications

Over the past few months we have noticed a clear trend: beyond traditional Application Security, Security DevOps, source code security analysis and penetration testing, clients increasingly ask us to review the architecture of their IT systems. Not as a box‑ticking exercise, but to support important business decisions. This is natural: as a product grows, security and quality requirements tighten, and the cost of architectural mistakes becomes higher than the cost of defects in code.

Recently we delivered several projects for SaaS companies and industrial organizations, assessing the quality, security, and resilience of architecture — both for public products and for internal systems. The requests varied: different requirements and different emphasis on specific architectural elements. In some projects we had to provide an executive answer to the questions like “can the product continue to be developed with the current engineering team?” or “how realistic is it to hand the system over to another team within 1–2 months without a support collapse?”, based on evidence from code, DEV/PROD observations, and objective metrics. In nother projects, we assessed the maturity of a data storage systems: trust boundaries, multi‑tenant mode, key and encryption management, admin access controls, logging, immutability, segmentation, and restore readiness backed by runbooks.

Some customers focus on source code quality: structure, complexity, hotspots, technical debt, testability, CI/CD maturity, and repeatable releases. Others care most about documentation quality: whether the system can be handed over to another team, whether up‑to‑date diagrams, runbooks, deployment and recovery instructions exist, and whether dependencies and single points of failure are clear. A third group focuses on maintainability risks: bus factor, change velocity, cost of fixes, and reproducibility of defects. A fourth group prioritizes security: tenant isolation, authorization quality, secret leakage, file and data security, configuration, protection against XSS/IDOR/SSRF, and software supply chain risks. A fifth group looks at resilience and scalability: performance degradation under load, dependency failure handling, redundancy, RPO/RTO, synchronization points, and bottlenecks. A sixth group wants all of the above — in that case we build a coherent as‑built picture and deliver a prioritized roadmap.

Sometimes customers explicitly ask us to align with specific security frameworks and standards: SABSA, NIST CSF, NIST SP 800‑53, NIST SP 800‑160, ISO/IEC 27001/27002, ISO/IEC 27005, ISO/IEC 15408 (Common Criteria), OWASP ASVS, OWASP SAMM, CIS Controls, MITRE ATT&CK, CSA CCM/STAR, and SOC 2 Trust Services Criteria.

Separately, for architecture and engineering maturity, we also see requests for TOGAF, ArchiMate, ISO/IEC/IEEE 42010, the C4 model, SEI ATAM, 12‑Factor App, Cloud Well‑Architected (AWS/Azure/GCP), DDD approaches, and SRE practices (SLO/SLI, error budgets).

At the same time, there is also another group of clients: they are not interested in “which model is correct”, but they need an evidence‑based answer to support a strategic decision. Examples of practical questions we hear regularly:

• Are there signs that the team is over‑relying on AI‑generated code without adequate quality and security controls?
• Can the system handle a 10× user growth without a major redesign?
• Are there tenant‑escape risks and data leakage between customers in a multi‑tenant product?
• Are there any backdoors, suspicious remote‑access mechanisms, unsafe debug paths, or embedded keys in the codebase?
• Can we trust the 2FA/session mechanism? Were critical controls disabled to “ship faster”?
• Is observability sufficient to investigate incidents and prove facts (logs, audit trails, traces)?
• Is the system ready for real recovery after ransomware encryption or an admin mistake, or does DR exist only “on paper”?

Our experience shows that when an architecture review is performed at the intersection of AppSec + DevOps/SecDevOps + business and systems analysis, the customer receives not just a list of technical notes, but a clear executive picture: what actually works, where the risks are, what to fix first and why, and which strategic plan will lead to sustainable operation.

If this is relevant for you, we can offer both a short one‑week, business‑goal‑driven audit (“decision‑oriented review”) and a deeper 3–4‑week assessment with DFD and trust boundaries, review of keys, encryption, access controls, logging, immutability, CI/CD and supply chain analysis, multi‑tenant isolation verification, and a prioritized strategic roadmap aligned with your business goals.

Contact us.