Encryption in Transit and at Rest: A Banker's IIBF ITSEC Guide

Every payment message, mobile banking login and core banking record a bank handles has to be protected using encryption in transit and at rest — the two states in which sensitive data exists, and the two states an IIBF IT Security paper tests most often. Bankers preparing for the ITSEC module need to know not just what these terms mean, but which mechanism protects which state, and where banks in India typically get it wrong. This article breaks down the practical controls behind encryption in transit and at rest, ties them to the current syllabus, and closes with exam-style MCQs.

🔐 What "In Transit" and "At Rest" Actually Mean

Data in transit is data moving across a network — a customer logging into internet banking, a mobile app calling the core banking API, or an NEFT/RTGS message travelling between a branch server and the payment system. Data at rest is data sitting still — rows in the core banking database, nightly backup files, log archives, or a CSV export sitting on someone's desktop.

Both states fall under the confidentiality leg of the CIA triad (confidentiality, integrity, availability), but they are protected by different mechanisms, and an exam question that mixes up "TLS protects data at rest" is a classic trap. The IIBF ITSEC syllabus covers this under Software Security Control, which treats encryption as one control among several — access control, logging and encryption together, not encryption alone.

A useful way to remember the split: if the data is moving, you need a secure channel; if the data is stored, you need the storage itself encrypted. A bank that encrypts one but not the other has only half a control, and auditors treat it that way.

🌐 Protecting Data in Transit: TLS, VPNs and Secure Channels

For customer-facing channels, TLS 1.2 or 1.3 over HTTPS is the baseline for internet banking and mobile apps — anything still negotiating SSL 3.0 or TLS 1.0 is a finding in any IT audit. Interbank and branch-to-datacentre traffic typically runs over a leased line or MPLS network with an additional VPN or IPsec tunnel, since a private network alone is not the same as an encrypted one.

Payment messaging adds a further layer: message-level encryption and digital signing so that even if a network segment were compromised, the payment instruction itself stays unreadable and tamper-evident. This overlaps with the perimeter and segmentation controls covered under Network Controls, where encryption is paired with firewalls and access control lists rather than treated as a standalone fix.

💡 Exam Tip: If a question asks what protects an NEFT message while it travels between systems, the answer is transport/message-level encryption (TLS, VPN, message signing) — not database encryption, which only protects the message once it is stored.

SFTP or encrypted file transfer should also replace plain FTP for any batch file exchange with vendors, aggregators or other banks. Plain FTP still shows up in legacy branch setups and is an easy, avoidable audit finding.

🗄️ Protecting Data at Rest: Databases, Backups and Storage

At the database layer, Transparent Data Encryption (TDE) encrypts data files on disk so that a stolen or improperly accessed disk image does not expose readable customer records. Full-disk encryption on servers and branch endpoints, and encryption of removable media, extend the same principle to storage outside the database itself. This is one of the areas covered in depth in our related piece on database security in banks.

Backups are where banks most often fall short. A production database can be fully encrypted while its nightly backup sits on an unencrypted tape, external drive, or cloud bucket with default settings — the sensitive data is identical, but the control silently disappears the moment it is copied.

⚠️ Common Mistake: Treating backup and archival storage as "already covered" because the source system is encrypted. Encryption does not travel with a copy automatically — each storage location needs its own encryption to be verified, backups and DR copies included.

Encryption also has to be distinguished from masking. Encryption is reversible with the right key and protects data wherever it is stored; masking replaces real values with fictitious ones for non-production use, such as test and UAT environments. Banks that confuse the two often leave real customer data in test systems because "it's masked" when it was never masked at all — a distinction covered in our note on data masking and tokenisation.

🏦 Regulatory Expectations and the ITSEC Syllabus

RBI's IT and cyber security framework for banks, first issued as a circular in 2016 and carried forward through the RBI Cyber Security and IT Directions, 2023, expects banks to protect customer and transaction data both in transit and at rest as part of a documented information security policy, not as an ad-hoc technical choice. The regulator does not prescribe one specific algorithm; it expects banks to adopt industry-accepted strong encryption and to be able to demonstrate it during an IT audit.

This sits alongside the standards and classification work covered under Security Standards And Best Practices and Asset Classification And Controls, where the level of encryption applied is expected to match the sensitivity classification of the asset — a customer PII field and an internal marketing spreadsheet do not need the same protection.

📌 Remember: Encryption is a technical control that implements a policy decision. The exam often frames questions around "which policy/standard governs this control" rather than the algorithm itself — read the question for that angle.

For the primary regulatory text, refer to RBI's official cyber security and IT framework guidance for banks rather than relying on secondary summaries when preparing for the exam.

⚙️ Where Banks Get This Wrong in Practice

Beyond the backup gap already covered, four patterns recur in IT audits. First, legacy branch servers or third-party integrations still negotiating weak cipher suites because nobody revisited the configuration after go-live. Second, database exports sent by email or shared drive for "quick testing," bypassing encryption entirely rather than working around it. Third, encryption keys stored alongside the encrypted data itself — technically encrypted, practically useless as a control, since anyone who reaches the data also reaches the key.

Fourth, and increasingly relevant, is algorithm longevity. Encryption chosen today needs to remain sound for the lifetime of the data it protects, which is why crypto-agility is now part of the conversation — a bank that cannot swap its encryption algorithm without a system rebuild is exposed the day a widely used algorithm is weakened. We cover this forward-looking risk in our piece on post-quantum readiness in banks.

None of these gaps are exotic; they are the same handful of findings that show up year after year in internal and RBI-mandated IT audits, which is exactly why they are popular exam material.

🧭 Building an Exam-Ready and Audit-Ready Checklist

For the exam, keep the state-to-mechanism mapping straight: transit needs a secure channel, rest needs encrypted storage, and both need key management that keeps the key separate from the data it protects. For practice, the same mapping is what an IT auditor checks, which is why ITSEC questions lean so heavily on real audit findings rather than theory.

A short working checklist: confirm TLS versions on every external-facing channel, confirm TDE or disk encryption on every database holding customer data, confirm backups and DR copies inherit the same encryption as production, confirm keys are stored separately from data (ideally in a hardware security module or key management service), and confirm test/UAT environments use masking rather than a raw copy of production. Each of these maps directly to a control area tested in the Security Standards And Best Practices chapter.

Read every ITSEC article on the topic together with the syllabus chapters rather than in isolation — the exam rewards candidates who can connect a control (encryption) to the threat it addresses and the standard that mandates it. Browse more coverage on the IT Security tag hub for related topics.

🧠 Practice MCQs: Encryption in Transit and at Rest

Want chapter-wise mock tests with 100+ MCQs? Start practising free →

Frequently Asked Questions

Encryption in transit and at rest is one of the few IT security controls that shows up in almost every ITSEC paper, precisely because it is where real banks keep failing real audits. Get the state-to-mechanism mapping solid, know where backups and keys typically go wrong, and practise it with full-length mocks on the CAIIB course page before exam day. As a parallel, the same preventive-control logic applies outside IT — in Risk Management for insurers, weak monitoring shows up as persistency risk in life insurance, where lapses erode value the same way an unencrypted backup erodes customer trust.