Security
Our clients trust us with operational data, personal data and the systems they rely on during a crisis. This page sets out how we protect that trust: who leads our security work, the standards we work to, and the controls we apply throughout development and support.
Leadership
Security at SyCIS is not delegated to a checklist. Our security architecture and assurance work is led by a Chartered Security Architect, a professional title that recognises proven, independently assessed expertise in designing secure systems.
That expertise shapes every engagement: it sets the security requirements, reviews the architecture, approves the access model and signs off each release. Security decisions are made by someone accountable for them, at the point where they are cheapest to get right.
Standards
We use internationally recognised frameworks so that our security is measurable, auditable and easy for your own assurance team to map against.
ISO/IEC 27001
Our working practices follow the ISO/IEC 27001 approach to managing information security: risk assessment and treatment, asset management, access control, supplier management, incident management and continual improvement.
NIST SP 800-53
We use the NIST SP 800-53 control catalogue to define and verify security requirements, including access control (AC), audit and accountability (AU), identification and authentication (IA), system and communications protection (SC) and system integrity (SI).
OWASP
Our engineers follow the OWASP Secure Coding Practices, and we use the OWASP Top 10 and the Application and Mobile Security Verification Standards (ASVS and MASVS) as baselines when testing web and mobile applications.
Secure development lifecycle
We use STRIDE threat modelling (spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege) to identify how a system could be attacked, then turn the results into explicit security and privacy requirements before design begins. Each one is recorded, with its source, in the project’s Requirements Traceability Matrix alongside all other functional and non-functional requirements.
Trust boundaries, data flows, authentication and the access model are reviewed and signed off by our Chartered Security Architect.
Code is written to OWASP practices and reviewed before it is merged, with security-relevant changes given particular scrutiny.
Static analysis, dependency scanning and secrets detection run automatically, so issues are caught when they are introduced.
Each release is tested against the agreed security requirements, and access-control rules are verified with automated tests.
Once live, software is monitored, patched and continuously scanned for new vulnerabilities for as long as we support it.
Vulnerability management
AI has changed the pace of vulnerability discovery. Automated, AI-driven scanning means weaknesses in public-facing software and open-source components are found, and exploited, faster than ever.
We assume our software is being scanned in this way, so we scan it first.
Application dependencies and build components are scanned regularly against public vulnerability databases, including the National Vulnerability Database and GitHub Security Advisories.
We use AI-assisted review alongside conventional scanners to find logic flaws and insecure patterns that signature-based tools miss.
Findings are prioritised by severity (CVSS) and by evidence of active exploitation, so the most dangerous issues are fixed first.
Secure by default
These protections are our defaults on every application, not optional extras.
We build highly secure stand-alone apps that have no need to connect to the internet once downloaded. With no server to attack and no data in transit, a whole class of risk is removed, which makes them well suited to sensitive or air-gapped environments.
All application data is retained in encrypted databases, whether it is stored on the user’s device or in the cloud. A lost device or a copied database file does not expose readable data.
Sensitive credentials such as passwords, tokens and encryption keys are stored in the Apple Keychain or the platform equivalent, such as Android Keystore, and never in plain app storage or source code.
Our apps include no tracking, analytics or advertising frameworks by default. Tracking functionality is added only when a client specifically asks for it, and then in line with data protection law.
Technical controls
Client confidentiality
Confidentiality is part of the service we provide, from the first conversation to long after a project ends.
We take client data leakage extremely seriously. We have robust processes to identify potential leaks of client data and block them before data leaves its intended boundary.
For both security and confidentiality, we protect the identity of our clients. We do not publish client names, logos or case studies, and we treat the fact that we work with you as confidential.
We are happy to sign a mutual or one-way non-disclosure agreement (NDA) before you share any sensitive information, and to work within your own confidentiality terms.
We are happy to complete security questionnaires and walk your assurance team through our approach.